RD-A147  269  fl  Q-GERT  NETWORK  SIMULATION  MODEL  FOR  EXAMINING  i/2 

PIPELINE  TIME  IN  THE  NAVY.  .  (U)  AIR  FORCE  INST  OF  TECH 
WRIGHT-PATTERSON  AFB  OH  SCHOOL  OF  SYST.  .  M  N  ROMERO 
UNCLASSIFIED  SEP  84  AFIT/GLM/LSM/84S-56  F/G  15/5  NL 


AF1T/G  LM/LSM/S4 


A  Q-GERT  NETWORK  SIMULATION  MODEL  FOft 
EXAMINING  PIPELINE  TIME  IN  THE  NAVY'S  J-52 
INTERMEDIATE  LEVEL  JET  ENGINE  REPAIR  CYCLE 

THESIS 


Michael  N.  Romero 
Lieutenant,  USN 

AFIT/G  LM/LSM/84S-56 


Approved  for  public  release;  distribution  unlimited 


The  contents  of  the  document  are  technically  accurate,  and 
no  sensitive  items,  detrimental  ideas,  or  deleterious  informa¬ 
tion  are  contained  therein.  Furthermore,  the  views  expressed 
in  the  document  are  those  of  the  authors  and  do  not  necessarily 
reflect  the  views  of  the  School  of  Systems  and  Logistics,  the  . 
Air  University,  the  United  States  Air  Force,  or  the  Department 
of  Defense. 


V?  \ 


AFIT/G  LM/LSM/84S-56 


A  Q-GERT  NETWORK  SIMULATION  MODEL  FOR 
EXAMINING  PIPELINE  TIME  IN  THE  NAVY'S  J-52 
INTERMEDIATE  LEVEL  JET  ENGINE  REPAIR  CYCLE 

THESIS 


Presented  to  the  Faculty  of  the  School  of  Systems  and  Logistics 
of  the  Air  Force  Institute  of  Technology 
Air  University 

In  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science  in  Logistics  Management 


Michael  N.  Romero,  B.S. 
Lieutenant,  USN 


September  1984 


Approved  for  public  release;  distribution  unlimited 


Preface 


The  goal  of  this  project  was  to  develop  a  computer  simulation  model  of  the 
repair  pipeline  for  the  U.S.  Navy's  J— 52  jet  engine.  Hopefully,  1  have  conveyed 
the  point  that  the  model  answers  no  single  question,  but  that  it  can  be  used  as 
a  management  tool  to  investigate  several  questions  or  problem  areas  dealing 
with  the  inefficient  use  of  resources. 

In  putting  this  model  together,  l  relied  on  existing  maintenance  directives, 
interviews,  and  personal  experience.  To  demonstrate  the  model's  application,  I 
established  a  hypothetical  scenario  with  contrived  parameters  in  order  to 
convert  the  model  to  code  and  run  it  on  the  computer.  Results  of  the  output 
are  explained  in  order  to  give  the  reader  some  idea  as  to  the  model's  use. 

A  great  deal  of  thanks  is  in  order  for  my  thesis  advisor,  Mr.  Jim  Meadows, 
for  his  patience  and  expert  guidance.  I  would  also  like  to  thank  LCDR  John 
VanSickle  at  NAVAIRSYSCOM  for  his  "in  the  field"  advice,  and  also  Dr.  Charles 
Fenno,  whose  scholarly  advice  helped  steer  me  away  from  making  this  report 
sound  like  it  was  written  by  a  government  employee. 

Words  cannot  express  my  sincere  appreciation  for  my  lovely  wife,  Nancy, 
and  her  countless  hours  of  typing  on  this  report.  She  and  the  children,  Mike, 
Larry,  and  Angela,  sacrificed  more  them  what  should  be  expected  as  this  thesis 
was  going  through  its  growing  pains. 

Finally,  I  humbly  express  my  deepest  thanks  to  the  Lord  who  carried  me  so 
securely  over  the  countless  hurdles  that  only  He  and  I  are  aware  of.  I  cannot 
imagine  ever  tackling  a  project  of  this  magnitude  without  Him. 
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Abstract 


Repairs  on  jet  engines  of  Naval  aircraft  are  performed  in  accordance  with  the 

three-level  concept  prescribed  by  the  Naval  Aviation  Maintenance  Program 

(NAMP)  -  organizational,  intermediate,  and  depot  level.  At  the  intermediate 

level,  the  entire  repair  cycle  is  referred  to  as  the  pipeline  and  includes  time 

expended  in  transit,  storage,  administrative  processing,  actual  repair,  awaiting 

maintenance  (AWM)  time,  and  awaiting  parts  (AWP)  time.  Existing  repair  system 

directives  specify  a  standard  turnaround  time.  (TAT)  for  engines  in  the  repair 

cycle  pipeline.  Recent  data,  however,  indicates-  that  the  actual  TAT  for  the 

J— 52  engine  is  almost  four  times  the  standard  specified  by  the  directives.  One 

* 

approach  to  investigating  this  excessive  time  in  the  pipeline  is  to  examine  the 
operation  of  the  repair  system,  focussing  attention  on  the  utilization  of 
resources.  The  objective  of  this  project,  therefore,  was  to  develop  a  computer 
simulation  model  which  replicates  the  J— 52  intermediate  level  repair  cycle, 
concentrating  on  repair  crews,  workstands,  and  test  cells  as  the  major  resources 
employed.  The  intended  use  of  the  model  is  as  a  management  tool  in  which 
backlogs  and  delays  at  various  points  in  the  pipeline  can  be  identified,  thereby 
allowing  managers  to  adjust  or  reallocate  resources  as  required  to  achieve  a 
more  efficient  operation  and,  hence,  a  lower  TAT.  A  hypothetical  scenario 
based  on  contrived  parameters  was  developed  in  order  to  convert  the  model  to 
code  and  demonstrate  its  application  on  the  computer.  The  results  of  a  sample 
simulation  run  show  that  excessive  repair  backlogs  and  delays  as  well  as 
inefficient  resource  utilization  can,  in  fact,  be  identified  in  the  output,  thereby 


A  Q-GERT  NETWORK  SIMULATION  MODEL  FOR 
EXAMINING  PIPELINE  TIME  IN  THE  NAVY’S  J-52 
INTERMEDIATE  LEVEL  JET  ENGINE  REPAIR  CYCLE 


I.  Introduction 


Chapter  Overview 

This  research  project  takes  an  investigative  look  at  a  key  management 
issue  within  the  Navy's  J-52  repair  system  using  simulation  modeling  as  the 
primary  tool.  This  first  chapter  provides  background  information  related  to  the 
J-52  repair  system,  followed  by  a  statement  of  the.  problem,  the  research 
objectives,  the  investigative  questions,  the  scope  and  limitations  of  the  project, 
the  assumptions  made,  and,  finally,  the  justification  for  the  research. 


Background 

The  Pratt  and  Whitney  J-52  turbojet  engine  is  one  of  the  most  widely 
used  engines  in  Naval  Aviation.  Three  models  of  the  J-52  engine  comprise  the 
current  active  inventory,  the  J-52-P-6B,  the  J-52-P-8B,  and  the  J-52-P-408. 
These  three  models,  along  with  the  average  operating  time  per  engine  in  each 
model  and  the  type  aircraft  employing  the  engine,  are  shown  in  the  following 
table.  Appendix  A  provides  a  listing  of  the  squadrons  using  these  engines  as 
well  as  their  homebase  locations. 


Engine  Model 

Avg.  Operating  Hours 

Type  Aircraft 

J-52-P-6B 

4,186 

TA-4J,  TA-4F,  EA-4F 

J-52-P-8B 

2,767 

TA-4J,  A-4E,  A-4F, 

0A-4M,  EA-6A,  A-6E, 

KA-6D 

J-52-P-408 

1,533 

A-4M,  A-4F,  EA-6B 

Over  1200  J— 52  engines  cure  required  "just  to  fill  the  slots"  of  the  aircraft 
using  this  engine.  The  Naval  Aviation  Maintenance  Program  (8)  authorizes  three 
levels  of  repair  for  the  J— 52  engine  according  to  the  complexity  and  time 
required  to  accomplish  repairs.  Currently,  47  designated  repair  sites  are 
authorized  to  perform  some  level  of  repair  ranging  from  minor  to  complete 
teardown  and  major  repair.  These  sites  include  CONUS  as  well  as  overseas  and 
carrier-based  repair  facilities  (9).  Appendix  B  provides  a  listing  of  these  repair 
sites. 

The  primary  responsibility  for  repair  of  the  J— 52  engine  lies  with  the 
Intermediate  Maintenance  Activity  (IMA).  This  placement  of  responsibility  is 
largely  a  result  of  policies  established  by  the  Engine  Analytical  Maintenance 
Program  (EAMP),  which  was  implemented  in  1978  (8).  The  EAMP  is  primarily 
concerned  with  the  establishment  of  maintenance  requirements  which  enable 
engines  to  perform  their  task  with  a  specific  probability  of  success  at  the 
lowest  possible  total  cost  for  system  operation  and  support  over  the  life  cycle 
of  the  engine  (8:  Vol.  Ill,  3-3-3). 

Prior  to  the  EAMP,  engines  were  removed  from  the  aircraft  not  only  for 
failures,  but  also  for  overhaul  at  a  depot  facility  on  a  scheduled  basis.  At  that 
time,  extensive  preventive  maintenance  was  performed,  and  known  discrepancies 
were  repaired.  For  engines  now  falling  under  the  EAMP  concept,  however,  more 


are  no  longer  any  scheduled  overhauls  at  the  depot  facility.  Engines  are 
removed  only  for  failures  or  for  the  accomplishment  of  certain  maintenance 
actions  by  the  IMA.  These  actions  may  include  inspections,  modifications,  or 
investigations  of  sustained  poor  performance  as  directed  by  the  appropriate 
command  authorities  (8:  Vol.  Ill,  3-3-3)*  The  services  of  the  depot  facility  are 
required  only  when  a  repair  job  is  beyond  the  capability  of  intermediate  level 
repair. 

The  Navy's  policy  in  engine  management  is  to  maintain  sufficient  spare 
aircraft  engines  to  support  established  peacetime  operating  objectives  as  well  as 
mobilization  and  emergency  requirements  (10:1).  "Engines  will  be  managed 
economically  and  in  a  manner  consistent  with  peacetime  support  requirements. 
This  requires  that  the  lengths  of  time  of  engine  pipeline  elements  such  as 
awaiting  transit,  in  transit,  awaiting  rework,  and  in-process  repair  be  reduced 
(10:1)."  Pipeline  elements  are  those  stages  through  which  an  engine  passes  as  it 
goes  through  the  repair  cycle.  These  stages  include  transit,  storage,  repair, 
awaiting-parts,  and  awaiting-maintenance. 

Standard  pipeline  times  for  all  Naval  aircraft  engines  are  established  (10). 
The  table  which  follows  shows  the  standard  times  established  for  the  J-52-P-8 
and  the  J-52-P-408.  These  two  models  represent  over  75%  of  the  J— 52  engines 
in  service.  The  data  in  the  table  (in  calendar  days)  is  broken  down  by  major 
elements  of  the  pipeline  and  the  site  from  which  the  engine  originated.  An 
engine  originating,  for  example,  at  the  organizational  level  ("0"  Level)  should 
experience  (according  to  the  standard)  an  average  repair  turnaround  time  of  26 
days.  Similarly,  an  engine  going  from  a  third  degree  facility  to  a  higher  level 
facility  for  repair  should  experience  an  average  total  amount  of  time  of  25  days 
in  the  pipeline. 


TOTAL 


26 


25 


24 


21 


One  of  the  goals  of  the  J  —52  intermediate  level  repair  system  is  to 
minimize  pipeline  time  and  maximize  engine  availability  (21;  38).  In  a  very  broad 
sense,  pipeline  time  (a  term  used  synonomously  with  turnaround  time)  begins 
once  an  engine  requiring  maintenance  has  been  removed  from  the  aircraft.  It 
ends  when  the  engine  has  been  returned  to  a  serviceable  condition  and  delivered 
to  an  operating  squadron  (38).  The  two  goals  or  measures  of  performance  - 
pipeline  time  and  engine  availability  -  are  complementary.  Shortening  the 
amount  of  time  an  engine  spends  in  the  repair  cycle  results  in  engines  returning 
to  use  quicker  to  satisfy  a  demand  for  a  serviceable  engine.  Thus  availability  is 
increased. 

The  ability  of  the  J— 52  repair  system  to  supply  the  fleet  with  serviceable 
engines  in  a  timely  manner,  particularly  under  conditions  of  fluctuating  demand, 
translates  directly  into  strategic  mobility.  Likewise,  a  sluggish  repair  system 
frought  with  backlogs  and  delays  tends  to  degrade  the  capability  to  respond 
quickly  to  a  crisis.  Sable  provides  this  definition  of  strategic  mobility: 


Strategic  mobility  is  the  player  which  translates  combat 
force  potential  into  combat  force  capability;  the  capability 
to  deter  and  the  capability  to  carry  out  a  flexible  response 
(34:44). 

Meeting  engine  availability  goals  is  essential  for  the  successful 
accomplishment  of  the  Navy's  strategic  mobility  objectives.  The  entire  logistics 
support  system  for  the  J  —52  must  be  capable  of  meeting  a  surge  demand  as 
would  be  encountered  in  wartime.  Failure  to  do  so  would  result  in  a  potential 
chokepoint  in  the  logistics  system  and  become  a  limiting  factor  in  the  ability  to 
respond  to  a  crisis. 

Strict  control  of  engine  assets  is  essential  in  order  for  managers  to  be 
aware  of  pipeline  time  and  spare  engine  availability.  Without  a  knowledge  of 
the  factors  causing  engine  delays  in  the  pipeline,  it  becomes  difficult,  if  not 
impossible,  to  forecast  spare  engine  availability,  particularly  under  the 
uncertain  conditions  of  wartime.  When  this  condition  occurs,  it  seriously 
hampers  the  efforts  of  defense  planners  to  develop  wartime  or  crisis 
contingency  plans.  Thus,  it  is  clear  that  the  Navy's  intermediate  level  repair 
system  becomes  a  focal  point  of  interest. 

Statement  of  the  Problem 

Despite  the  standard  established  for  turnaround  time,  the  repair  system 
for  the  J— 52  engine  is  not  performing  as  desired.  Turnaround  time  (TAT)  has 
increased  significantly  in  the  last  four  years,  as  seen  in  Figure  1  (see  Appendix 
C  for  data).  The  dotted  line  between  the  FY-82  and  FY-83  data  points  indicates 
that  the  TAT  for  FY-83  is  an  estimate  since  the  actual  figure  was  not 
available.  It  is  still  clear,  however,  that  TAT  has  experienced  almost  a  fourfold 


0 
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Figure  1.  J— 52  IMA  Engine  Turnaround  Time  (11:2) 

This  increase  has  had  detrimental  effects  on  J— 52  engine  availability. 
"Turnaround  time  has  increased  so  much  with  so  many  engines  in  the  pipeline 
that  we  do  not  have  the  spares  we  need,  and  we  are  not  ready  for  mobilization 
under  these  conditions"(21).  It  seems  clear  that  there  is  a  need  to  examine  those 
elements  of  the  pipeline  causing  delays  in  the  repair  cycle  in  order  to  get  the 
turnaround  time  back  down  to  the  standard. 

To  acquire  data  on  the  full  impact  of  this  degraded  repair  posture,  the 
Aircraft  Intermediate  Maintenance  Support  Office  (A1MS0)  at  Patuxent  River, 
Maryland,  conducted  a  study  to  identify  factors  which  were  contributing  to  the 
problem  of  an  increase  in  the  number  of  engines  in  the  pipeline  and  a 
lengthened  turnaround  time.  The  results  of  the  study  are  contained  in  a  report 
issued  by  the  A1MS0  (11).  This  report,  along  with  several  interviews  with  engine 
managers,  identifies  the  following  contributory  factors: 


1.  Awaiting  Parts  (AWP)  time  has  shown  an  increase  over  a  four  year 
period,  causing  engines  to  wait  longer  in  the  repair  system  before 
being  returned  to  use.  (See  Appendix  D). 

2.  Thirty-one  IMA  sites  transferred  a  total  of  291  engines  over  a  four 
year  period  to  another  repair  site  for  repairs  which  could  have 
been  accomplished  at  the  original  location.  Reasons  for  the 
transfers  were  not  provided  by  the  report.  (See  Appendix  E). 

3.  The  age  of  some  of  the  older  J-52  engines  is  causing  the  pipeline 
quantity  to  grow  (38).  Failure  data,  according  to  the  Naval 
Engineering  Support  Office  (NESO)  at  Jacksonville,  Florida, 
indicates  that  the  two  older  models  (P-6B  and  P-8B)  have  reached 
the  "wearout"  phase  in  their  life  cycle  (See  Appendix  F). 
Commensurate  with  this  phase  is  a  higher  failure  rate  for  these 
engines  resulting  from  the  deteriorated  material  condition  and 
degraded  engine  performance  (28).  Thus,  a  higher  failure  rate  has 
served  to  feed  engines  into  the  repair  cycle  at  a  higher  rate, 
causing  the  pipeline  quantity  to  grow. 

4.  The  deteriorating  quality  of  engine  repairs  was  also  suggested  as  a 
factor  contributing  to  the  growth  in  the  number  of  engines  in  the 
pipeline  (11:5;  21;  38).  Data  from  the  A1MS0  report  indicates  that 
over  a  four  year  period  4,248  engines  were  repaired.  Of  these, 
20%  (835)  were  subsequently  removed  from  the  aircraft  and 
re-submitted  for  repair  prior  to  fifty  operating  hours.  While  no 
interpretation  of  repair  quality  was  provided,  nor  any  link 
established  between  these  removals  and  repair  quality,  the  data 
does  suggest  an  investigation  is  warranted  to  determine  if  repair 
quality  is,  in  fact,  contributing  to  pipeline  growth. 


In  summary,  the  factors  contributing  to  pipeline  growth  are  many  and 
have  resulted  in  a  degraded  repair  posture  for  the  J-52  engine.  "These  factors 
having  an  impact  on  pipeline  growth  can  be  lumped  under  inefficiencies, 
deficient  training,  inadequate  repair  system  organization,  and  insufficient 
on-hand  spare  parts  availability"  (21). 

The  Navy's  response  to  finding  a  solution  to  this  problem  ham  been  to 
conduct  a  site  consolidation  study  (30).  The  objective  of  the  study  is  to 
determine  if  consolidation  of  selected  repair  sites  will  improve  the  J-52  repair 
support  posture  by  decreasing  pipeline  time  aind,  hence,  increasing  engine 
availability.  Phase  1  of  the  study  (Preliminauy  Analysis)  has  been  completed. 
Phase  II  (In-Depth  Study)  is  in  progress  at  this  time. 


Regardless  of  the  approach  taken,  it  would  appear  that  any  proposed 
solution  must  be  supported  by  an  accurate  model  of  the  J— 52  pipeline.  The 
model  must  be  able  to  identify  the  various  elements  of  the  pipeline  where 
excessive  time  accumulation  occurs  as  a  result  of  such  items  as  backlogs, 
shortages  of  resources,  or  inefficiencies.  The  model  must  also  be  able  to 
examine  changes  in  pipeline  time  as  certain  input  levels  (resources)  are 
manipulated. 


Research  Objectives 


The  objectives  of  this  research  project  were  twofold.  First,  a  network 
simulation  model  was  constructed  which  replicates  the  J-52  intermediate  level 
repair  cycle  as  closely  as  possible.  The  model  focusses  on  turnaround  time  (TAT) 
as  the  primary  measure  of  performance  of  the  repair  system.  The  input  factors 
for  the  model  are  the  main  resources  available  to  the  repair  system:  repair 
crews  and  engine  works tands.  Second,  the  operation  of  the  model  was  verified. 
The  times  for  the  various  processes  in  the  repair  cycle  were  estimated  as  well 
as  the  probabilities  associated  with  the  occurrence  of  the  processes.  Then  the 
model  was  coded  and  run  on  a  computer  to  demonstrate  its  performance. 


Research  Question 


The  following  research  question  sets  the  direction  for  this  project: 
Can  a  network  simulation  model  be  constructed  which 


would  accurate! 


rovide  a  decision-making  tool  for  managers  in  analyzin 


[•Yir 


In  carrying  out  the  research  for  this  thesis  project,  obtaining  answers  to 
the  following  investigative  questions  aided  in  answering  the  main  research 


question: 

-  What  are  the  major  elements,  or  processes,  of  the  J— 52 
repair  cycle  pipeline? 

-  What  relationships,  if  any,  exist  between  these  elements? 

-  Based  on  historical  data,  how  many  repairs  undergo  each 
process  identified  above? 

-  Which  network  simulation  technique  best  describes  the 
J— 52  repair  cycle? 

-  How  do  the  input  factors  (resources)  influence  the  output 
measures  of  performance  (turnaround  time)? 


Scope  and  Limitations 


The  following  are  some  of  the  constraints  and  limitations  placed  on  this 
research  project: 

-  The  model  replicates  the  pipeline  associated  with  a  first 
degree  intermediate  level  repair  facility. 

-  Only  CONUS,  shore-based  facilities  are  considered,  and 
not  carrier-based  or  overseas  facilities. 

-  Turnaround  time  is  the  only  output  measure  being 
examined  by  the  model. 

-  The  relative  merits  of  site  consolidation  (the  alternative 
currently  under  investigation  by  the  Navy)  is  not 
addressed  In  this  project. 

-  No  attempt  is  made  to  explain  the  reason  for  the 
existence  of  pipeline  deficiencies  causing  extended 
turnaround  times. 

-  The  model  does  not  address  the  details  of  the  operation 
of  a  depot  level  facility.  Even  thorqh  engines 
occasionally  pass  through  that  portion  of  ne  pipeline, 
addressing  changes  in  the  structure  and  operation  of  a 
depot  facility  is  extremely  difficult  because  of  the 
complexity  of  its  operation.  Thus,  the  model  treats  in 
detail  only  those  portions  of  the  pipeline  where  IMA 


managers  have  the  greatest  flexibility  in  making  changes 
for  improvement.  The  flow  of  an  engine  through  a  depot 
facility  is  treated  only  as  a  time  delay  in  the  pipeline. 


Assumptions 


Since  this  was  a  first  attempt  at  a  network  model  of  the  J— 52  repair 
cycle,  certain  assumptions  were  made  in  order  to  simplify  the  construction  and 
understanding  of  the  model.  These  assumptions  include: 

-  All  like  repair  crews  are  equally  skilled.  Additionally,  no  distinction  is 
made  between  skill  levels  of  individual  crew  members. 

-  The  quantity  of  resources  available  (repair  crews  and 
engine  works  tands)  remains  fixed  over  the  period 
prescribed  by  the  simulation. 

-  Parts  are  supplied  through  normal  supply  channels  and  not 
through  cannibalization.  (Cannibalization  is  the  removal 
of  needed  parts  from  other  engines  undergoing  repair 
when  the  parts  are  not  readily  available  through  normal 
supply  channels). 

• 

-  The  IMA  performs  both  unscheduled  maintenance  (repairs 
for  failures),  and  scheduled  maintenance  (inspections  and 
modifications). 

-  The  IMA  provides  repair  support  for  certain  activities  at 
remote  CONUS  locations  as  well  as  those  in  the 
immediate  area. 


Justification  for  the  Research 

Engine  managers  are  accountable  for  the  efficient  and  effective 
performance  of  the  J— 52  repair  system.  In  many  cases,  however,  this 
accountability  is  hampered  by  a  lack  of  information  regarding  system 
performance  (14:120).  Given  this  absence  of  objective  information,  managers 
often  must  make  arbitrary  judgements  about  such  crucial  management  issues  as 
goal  setting,  personnel  assignments,  work  schedule  development,  and  resource 


allocation.  The  resulting  situation  is  often  like  navigating  in  a  fog  with  no 
compass  -  decisions  are  made  on  intuition  alone  (2). 


A  simulation  model  will  aid  managers  in  decision-making  by  providing 
objective  Information  about  the  repair  cycle  pipeline.  Some  of  the  possible  gains 
Include: 


-  Identification  of  areas  in  the  pipeline  where  excessive  engine  backlogs 
occur. 

-  The  ability  to  reallocate  idle  resources  such  as  crews  and 
works tands  to  the  points  where  these  backlogs  occur. 

-  The  ability  to  investigate  alternative  work  scheduling 
plans  to  reduce  pipeline  time. 

-  Identification  of  inefficient  processes  in  the  pipeline 
where  training  or  management  attention  is  required. 


11.  Literature  Review 


Chapter  Overview 

Before  proceeding  with  the  model  development  in  Chapter  111,  it  is 
appropriate  first  to  consider  the  literature  on  the  system  being  modeled  as  well 
as  the  simulation  techique  employed.  A  discussion  of  the  intermediate  level  jet 
engine  repair  cycle  is  presented  first.  This  discussion  begins  with  the  broader 
issues  of  aviation  maintenance  addressed  by  the  Naval  Aviation  Maintenance 
Program  (NAMP),  and  eventually  focusses  on  specific  NAMP  concepts  which 
govern  jet  engine  maintenance.  Following  this,  some  specific  applications  of 
simulation  modeling  are  provided.  These  applications  relate  not  only  to 
simulation  in  general,  but  also  to  the  specific  simulation  technique  employed  in 
this  project.  Uses  of  simulation  in  both  the  commercial  and  the  D.O.D.  sector 
are  addressed. 


The  Naval  Aviation  Maintenance  Program  (NAMP) 

Description  of  the  Program.  The  NAMP  is  an  integrated  system  for 
providing  maintenance  and  all  related  support  functions  on  aeronautical 

equipment  (8:  Voi  I,  1).  The  program  is  sponsored  and  directed  by  the  Office  of 

the  Chief  of  Naval  Operations  (CNO)  and  serves  as  the  ultimate  authority  for 

matters  pertaining  to  the  maintenance  and  support  of  Naval  aeronautical 

equipment.  Formally  established  on  26  October  1959,  the  NAMP  has  undergone 
several  periodic  revisions  in  order  to  stay  abreast  with  the  changes  in 
complexity  of  modem  Naval  jet  aircraft.  The  current  version,  OPNAV 


Instruction  4790.2B,  was  issued  in  1977  and  serves  as  a  guide  for  aviation 
maintenance  managers  at  all  levels. 


Policies  established  by  the  NAMP  are  carried  out  by  the  Chief  of  Naval 

Material  via  the  Commander,  Naval  Air  Systems  Command  (NAVAIRSYSCOM)  in 

Washington,  D.C.  As  the  coordinating  authority  for  the  conduct  of  the  NAMP  (8: 

Vol.I,  1-3-6),  NAVAIRSYSCOM's  duties  include: 

-  Providing  guidance  on  all  aviation  maintenance  policies  and  procedures 
addressed  by  the  NAMP,  and 


-  Providing  technical  direction  and  management  review  of 
the  program  at  all  levels  of  maintenance. 


Objectives  of  the  NAMP.  The  primary  objectives  of  the  Naval  Aviation 
Maintenance  Program  are  twofold: 

-  To  achieve  and  maintain  the  material  condition  standards 
for  aeronautical  equipment  as  directed  by  the  Chief  of 
Naval  Operations,  and 

# 

-  To  fully  support  the  CNO  safety  program. 

Both  of  these  objectives  are  to  be  accomplished  while  minimizing  total 
resource  requirements  (8:  Vol  1,  2-1-1). 

The  Three— Level  Maintenance  Concept.  To  carry  out  these  objectives,  the 
NAMP  employs  the  three-level  maintenance  concept  as  established  by  the 
Department  of  Defense.  Repairs  on  aeronautical  equipment  are  to  be  performed 
at  that  level  of  maintenance  which  ensures  optimum  economic  use  of  resources 
(8:  Vol  I,  2-1-1). 

The  lowest  level  of  repair  is  referred  to  as  organizational  maintenance. 
This  involves  the  upkeep  maintenance  functions  performed  by  an  operating  unit 
on  a  day-to-day  basis  in  support  of  its  own  operations.  These  functions  normally 
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include  inspections,  servicing,  equipment  handling,  on-equipment  corrective  and 
preventive  maintenance,  tasks  assigned  by  technical  directives,  and  routine 
record  keeping  and  report  preparation. 

The  next  level  of  repair  is  referred  to  as  intermediate  maintenance.  This 
encompasses  the  repair  of  aeronautical  equipment  in  support  of  user 
organizations.  Its  functions  normally  consist  of  calibration,  off-equipment  repair 
or  replacement,  the  manufacture  of  certain  non-available  parts,  the 
accomplishment  of  certain  periodic  inspections,  and  the  provision  of  technical 
assistance  to  user  organizations.  These  functions  are  generally  held  to  be 
beyond  the  capability  of  operating  units. 

Depot  maintenance  is  the  highest  level  of  repair  authorized.  This  refers 
to  rework  maintenance  performed  on  aeronautical  equipment  requiring  major 
overhaul  or  a  complete  rebuilding  of  parts,  assemblies,  and  subassemblies.  Depot 
maintenance  functions  include  the  manufacture  of  parts,  modifications,  testing, 
and  reclamation  as  required.  These  facilities  support  the  lower  categories  of 
maintenance  by  providing  engineering  assistance  and  by  performing  maintenance 
that  is  beyond  the  capabilities  of  the  lower  level  facilities. 

The  three-level  maintenance  concept  provides  certain  management 
capabilities  (8:  Vol  I,  1-1-1).  These  include: 

-  The  classification  of  maintenance  functions  at  a  specific 
level, 

-  The  assignment  of  maintenance  tasks  consistent  with  the 
complexity,  depth,  and  scope  of  work  to  be  performed, 

-  The  accomplishment  of  a  particular  task  at  a  level  which 
will  ensure  optimum  economic  use  of  resources,  and 

-  the  collection,  analysis,  and  use  of  pertinent  data  to 
assist  all  levels  of  management  concerned  with  the 
NAMP. 


The  Intermediate  Level  of  Maintenance.  This  project  is  concerned  primarily  '  /'■] 
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with  the  intermediate  level  of  maintenance.  Thus,  certain  aspects  of  this  level 
are  examined  further. 

An  Intermediate  Maintenance  Activity  (IMA)  comprises  all  departmental 
units  responsible  for  providing  intermediate  level  maintenance  support  ashore 
and  afloat.  A  shore-based  IM  A  normally  consists  of  the  following  departments: 

-  Aircraft  Intermediate  Maintenance  Department  (A1MD), 

-  Supply  Department, 

-  Weapons  Department, 

-  Public  Works  Department. 

Of  these  four,  the  AIMD  is  responsible  for  performing  intermediate  level 
maintenance  functions  on  aircraft  and  aeronautical  equipment. 

The  AIMD  is  authorized  to  perform  only  those  maintenance  functions 
specified  by  the  NAMP  for  intermediate  level  repair.  To  determine  if  a  repair 
can  be  undertaken,  the  AIMD  consults  the  appropriate  Maintenance  Instruction 
Manual  (MIM)  to  determine  the  functions  required  to  accomplish  the  repair.  If  a 
function  falls  beyond  the  capability  of  the  AIMD,  the  equipment  is  sent  to  a 
higher  level  activity  for  repair. 

Since  the  intermediate  level  repair  for  engines  is  the  focal,  point  for  this 
project,  it  is  appropriate  to  consider  the  maintenance  functions  which  may  be 
performed  by  the  Powerplant  Division  of  an  AIMD.  According  to  the  NAMP  (8: 
Vol.  Ill,  1-1-6),  the  following  intermediate  level  repair  functions  may  be 
performed  on  powerplants  and  related  systems: 

-  Periodic  Inspection  (engine  installed  or  removed), 

-  Functional  test  and  adjustment  utilizing  engine  run-up 
stand, 

-  Repair  of  engine  systems  and  components, 

-  Repair  of  removed  auxilliary  power  units,  and 

-  Preservation  anc.  depreservation  of  uninstalled  engines. 


The  Three  —  Degree  Gas  Turbine  Engine  Repair  Program.  The  repair  of  jet 
engines  at  the  intermediate  level  is  governed  by  the  Three-Degree  Gas  Turbine 
Engine  Repair  Program.  Operating  under  the  jurisdiction  of  the  NAMP,  this 
program  provides  the  policies  cind  procedures  for  the  accomplishment  of  engine 
repairs  by  the  Powerplants  Division  of  ALMD.  This  program  is  contained  in 
NAVA1RSYSC0M  Instruction  13700.10  series. 

Under  the  Three-Degree  Gas  Turbine  Engine  Repair  Program,  each 
intermediate  level  jet  engine  maintenance  manual  defines  specific  maintenance 
actions  as  either  first  degree,  second  degree,  or  third  degree  functions.  These 
maintenance  functions  are  determined  largely  by  the  degree  of  difficulty  and 
recurring  frequency  (8:  Vol.  Ill,  3-3-1).  Selected  IMA's  are  assigned  to  provide  a 
specific  degree  of  support  for  certain  engines.  This  assignment  is  based 
primarily  on  the  type  and  number  of  engines  supported  within  the  geographical 
region. 

Beginning  at  the  lowest  level,  third  -  degree  repair  encompasses  primarily 
certain  engine  inspections.  It  also  includes  some  minor  repair  functions  which 
have  a  high  incidence  rate  but  low  maintenance  manhour  requirement. 
Second-degree  repair  refers  to  the  repair  of  discrepant  gas  turbine  engines 
which  normally  require  the  repair  and/or  replacement  of  turbine  rotors, 
combustion  section  components,  and  afterburners.  Maintenance  on  the 
compressor  section  is  limited  to  minor  repairs.  First-degree  repair  refers  to  the 
repair  of  discrepant  engines  which  require  compressor  rotor  replacement,  and/or 
disassembly  to  the  extent  that  the  compressor  rotor  could  be  removed. 
Additionally,  any  repair  requirement  that  goes  beyond  the  capability  of  a 
second-degree  facility  but  does  not  require  depot  level  repair  is  defined  as 
first-degree  repair. 
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The  Engine  Repair  Cycle  Pipeline.  The  final  topic  pertaining  to  the  Naval 
Aviation  Maintenance  Program  addresses  the  flow  of  an  engine  through  the 
repair  cycle  pipeline.  Two  viewpoints  are  provided  along  with  a  graphical 
illustration  of  both.  The  first  viewpoint,  shown  in  Figure  2,  represents  the 
interaction  of  the  three  levels  of  maintenance  from  a  macro  perspective.  The 
three  levels  of  maintenance,  as  mentioned  previously,  are  the  organizational, 
intermediate,  and  depot  level.  (The  Supply  Support  Center  is  included  in  the 
figure  because  of  its  central  role  in  controlling  engine  movements,  although  it  is 
not  to  be  confused  with  the  three  levels  of  maintenance). 

According  to  Figure  2,  engines  declared  "not  locally  repairable"  at  the 
organizational  level  are  turned  in  to  the  Supply  Department  and  a  replacement 
is  issued  from  the  spare  engine  pool  if  available.  Supply  then  inducts  the 
retrograde  engine  into  the  IMA  for  repair.  The  IMA  either  repairs  it,  or  sends  it 
to  a  facility  with  higher  level  repair  capability.  The  dashed  line  between  the 
IMA  and  the  Supply  Support  Center  indicates  communication  of  the  engine 
status  and  coordination  for  shipping  of  the  engine  to  another  facility  for  repair. 
Eventually,  the  repaired  engine  is  returned  to  the  spare  engine  pool  for 
subsequent  issue  as  required. 

In  reality,  the  actual  flow  of  engines  is  made  much  more  complex  by 
factors  not  revealed  in  the  figure.  In  the  case  of  the  J-52,  for  example,  bases 
rarely  experience  the  luxury  of  an  actual  spare  engine  pool.  The  demand  for 
serviceable  engines  as  well  as  the  growth  of  the  repair  pipeline  (as  discussed  in 
Chapter  l)  have  necessitated  a  tightly  controlled  policy  for  assignment  of 
serviceable  engines  (24).  Many  engines  experiencing  a  failure  and  receiving 
repairs  at  one  base  will  often  be  assigned  to  fill  a  demand  at  some  remote 
location  rather  than  staying  at  the  original  base.  These  engine  assignments  are 
made  in  accordance  with  guidance  from  higher  echelon  management. 


The  second  viewpoint,  shown  in  Figure  3,  illustrates  the  flow  of  an 
engine  through  the  repair  cycle  again,  but  in  more  detail.  The  flowchart 
describes  from  a  micro  perspective  the  key  decisions  and  processes  at  the 
intermediate  level  of  maintenance  which  govern  the  particular  path  an  engine 
will  take.  The  heavy  dark  lines  indicate  engine  flows,  while  the  dashed  lines 
indicate  a  communication  link  between  two  points. 

From  the  flowchart,  all  engines  Inducted  into  the  IMA  for  maintenance 
require  either  scheduled  or  unscheduled  maintenance.  The  first  decision  made  is 
whether  or  not  the  required  maintenance  is  within  the  IMA's  capability.  If  it 
is,  a  decision  is  made  as  to  whether  a  pre-induction  test  cell  run  is  required  of 
the  engine  in  order  to  troubleshoot  the  discrepancy  further  before  attempting 
repairs.  If  the  engine  is  not  repairable  locally,  it  is  forwarded  to  a  higher  level 
IMA  facility  or  to  the  depot  facility. 

Once  an  engine  is  inducted  for  maintenance,  it  will  require  either  major 
or  minor  repair.  Major  repairs  have  substantially  greater  requirements  than 
minor  repairs,  both  in  the  preparation  stage  and  the  actual  repair  stage. 
Regardless  of  the  extent  of  maintenance  required,  however,  engines  may  incur 
Awaiting  Parts  time  (AWP)  or  Awaiting  Maintenance  time  (AWM).  These 
involve,  respectively,  time  delays  associated  with  acquiring  needed  parts  or  with 
tending  to  other  maintenance  matters. 

The  flowchart  indicates  that  engines  may  need  to  have  QEC  components 
removed  prior  to  performing  maintenance  on  the  engine.  QEC  (Quick  Engine 
Change)  components  are  certain  externally  mounted  items  on  the  engine  which 
serve  to  adapt  the  engine  to  a  particular  aircraft.  The  components  Include  such 
items  as  hydraulic  pumps,  oil  drain  lines,  and  certain  electrical  components. 
Removal  of  these  items  is  often,  but  not  always,  necessary  to  facilitate 
maintenance  on  the  engine. 


Figure  3.  Flowchart  of  the  Intermediate  Level  Repair 
Cycle  Pipeline  (8:Vol.  Ill) 
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Once  maintenance  on  the  engine  is  complete,  a  determination  is  made  as 
to  whether  a  test  cell  run  is  required  to  verify  that  the  engine  is,  in  fact, 
serviceable  and  RF1  (Ready  For  Issue).  If  the  discrepancy  persists  after  a  test 
cell  run,  further  investigation  is  required  to  determine  if  the  engine  can  still  be 
repaired  locally,  or  whether  it  must  be  sent  to  a  higher  level  facility.  RF1 
engines  are  returned  to  the  Supply  Support  Center  (SSC)  for  issue  to  fill  the 
next  demand. 

Applications  of  Simulation 

Having  presented  a  brief  overview  of  the  structure  and  key  concepts  of  the 
intermediate  level  maintenance  program,  attention  is  now  turned  to  applications 
of  simulation  modeling.  The  few  applications  mentioned  in  this  section  provide 
only  a  representative  sampling  of  how  managers  are  using  this  approach  in 
studying  and  analyzing  various  systems  in  the  heart  of  many  industrial  and 
social  organizations.  First,  some  general  areas  where  simulation  has  been 
applied  is  discussed.  Following  this,  some  specific  areas  where  Q-GERT  has 
been  applied  are  also  discussed. 

Q-GERT  was  selected  as  the  simulation  language  most  appropriate  for  this 
project  as  a  result  of  its  capability  for  modeling  queueing  situations  such  as 
those  encountered  in  the  J— 52  repair  system.  Appendix  G  provides  a  substantive 
discussion  on  the  background  of  modeling  and  simulation  as  well  as  the 
justification  for  employing  Q-GERT  in  this  project.  For  more  detailed 
information  on  Q-GERT,  the  reader  is  referred  to  Appendix  H  which  describes 
Q-GERT  network  symbology. 
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General  Areas.  As  a  result  of  its  ease  of  manipulation  and  the  advantages 
gained  over  direct  experimentation,  simulation  has  been  applied  in  a  number  of 
different  settings.  Countless  articles  and  books  on  the  topic  attest  to  its 
widespread  popularity.  Applications  of  simulation,  for  example,  can  be  found  in 
the  fields  of  business  (16;  26;  29),  politics  (5),  behavioral  science  (20;  37), 
transportation  (23),  and  numerous  other  fields.  Day  and  Hottenstein  (7)  list 
some  general  areas  where  effective  use  of  job  shop  simulation  has  benefitted 
management.  These  include  the  ability  to  forecast  shop  workload,  the  planning 
of  shop  layout,  the  scheduling  of  critical  resources,  and  the  testing  of  various 
sets  of  operating  decisions. 

GERT,  the  family  of  simulation  languages  to  which  Q-GERT  belongs,  is  only 
one  of  the  techniques  available  for  simulation,  and  is  applied  in  various  settings. 
Elmaghraby  (13:323)  comments  that  GERT  simulation  has  been  used  to  model  and 
analyze  contract-bidding  situations,  population  dynamic  behavior,  maintenance 
and  reliability  studies,  vehicle  traffic  networks,  accident  causation  and 
prevention,  computer  algorithms,  and  many  other  areas  of  investigation  too 
numerous  to  mention.  GERT  simulation  has  also  been  successfully  applied  to 
industrial  sales  negotiations  and  cost  planning  for  corporate  level  decisions  (3; 
32). 


Specific  Q— GERT  Applications.  The  focal  point  of  interest  for  this  section 
on  application  is  on  the  specific  areas  in  which  Q-GERT  has  been  applied.  One 
of  many  examples  is  found  in  the  transportation  industry,  particularly  in 
intermodal  transportation. 

Intermodal  transportation  refers  to  shipments  of  freight  between  two 
locations  in  such  a  manner  that  two  or  more  modes  (truck,  rail,  air,  ocean 
vessel)  participate  in  the  movement  to  accomphish  its  delivery.  Increases  in  the 
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use  of  intermodal  transportation  is  very  probable  in  the  future  and  is  “very 
much  dependent  on  the  development  of  new  technology  for  both  the  intermodal 
terminal  areas  and  transportation  methods  (18:55).“ 

To  this  end,  Hammesfahr  and  Clayton  (18:55-68)  conducted  a  computer 
simulation  study  to  determine  ways  of  improving  efficiency  in  intermodal 
terminal  operations.  The  three  primary  areas  of  concern  in  this  study  were  as 
follows: 

-  At  what  level  of  demand  for  intermodal  traffic 
would  the  terminal  facilities  become  saturated? 

-  What  scheduling  or  procedural  changes  in  existing 
operations  would  result  in  greater  efficiency? 

-  Can  efficiency  be  improved  and  cost-effectiveness 

be  maintained  by  relocating  and  modifying  existing 
facilities,  or  by  acquiring  additional  support? 

The  primary  tool  for  this  study  was  a  Q-GERT  network  model  which 
facilitated  the  simulation  process  and  avoided  the  need  for  direct 
experimentation  at  fhe  terminals  which  would  cause  disruption  of  service.  The 
model  aided  in  the  analysis  of  parking  lot  requirements,  alternate 
loading/off-loading  procedures,  alternate  ramp  procedures,  capacity 
requirements  for  ramps,  ports  and  sidings,  proposals  for  new  facilities,  and 
measures  of  terminal  performance.  Because  of  its  graphical  nature,  Q-GERT 
offered  an  ideal  method  of  visualizing  the  flow  of  transactions  (trucks,  ships, 
etc.)  through  the  system.  It  also  enabled  managers  with  limited  simulation 
experience  to  obtain  a  reasonable  and  comprehensible  understanding  of  a 
complex  system. 

Q-GERT  has  also  had  an  impact  in  the  D.O.D.  as  well.  A  study  was 
conducted  to  develop  a  Q-GERT  simulation  model  of  the  supply  requisition 
processing  functions  at  the  Naval  Supply  Center,  San  Diego,  California  (15).  The 
objective  was  not  only  to  identify  the  most  efficient  means  of  routing  a 


requisition  through  the  system,  but  also  to  pinpoint  backlog  problems  and 
inadequate  resources  at  each  service  activity.  Through  this  study,  management 
could  identify  the  "best”  allocation  of  resources  within  specified  constraints. 

Another  D.O.D.  application  involved  the  use  of  Q-GERT  to  simulate  the 
maintenance  support  requirements  for  avionics  equipment  on  newly  proposed 
weapon  systems  (25).  This  study  yielded  a  model  which  provided  managers  with 
the  informatiion  necessary  for  determining  the  required  level  of  resources  (eg., 
manpower  and  test  equipment)  for  supporting  the  avionics  systems  of  new 
aircraft.  A  separate  but  related  study  (4)  applied  queueing  theory  in  determining 
the  proper  quantity  of  test  equipment  required  to  support  the  F-16  avionics 
systems.  By  using  Q-GERT  modeling,  the  avionics  component  repair  cycle  for 
the  F-16  was  simulated  and  the  authors  were  able  to  determine  the  optimal 
number  of  F-16  avionics  test  sets  to  acquire  in  order  to  achieve  the  greatest 
reduction  in  awaiting  maintenance  time. 

Finally,  a  study  was  conducted  to  determine  those  factors  that  significantly 
affect  an  Air  Force  intermediate  level  propulsion  branch's  ability  to  provide  a 
steady  supply  of  spare  aircraft  engines.  Using  a  Q-GERT  model,  the  Base  Level 
Repair  process  for  the  TF-33  P7/7A  engine  at  a  MAC  base  was  simulated  (6). 
Four  critical  factors  influencing  Mean  Repair  Time  were  identified  and 
incorporated  into  the  model.  The  objective  of  the  model  was  to  prescribe  a 
resource  allocation  plan  which  would  achieve  the  "best"  measure  of  engine 
support. 

Admittedly,  the  DOD  applications  described  herein  are  the  results  of  thesis 
efforts  and  do  not  reflect  "tried  and  proved"  methods  in  their  respective  areas. 
Nevertheless,  considering  the  fact  that  Q-GERT  fs  a  relatively  new  tool  which 
must  gain  further  acceptance  in  the  D.O.D.  through  proven  applications,  these 
studies  do  point  out  some  of  the  possibilities  where  it  can  be  applied.  It  is 


III.  Methodolot 


Chapter  Overview 

The  purpose  of  this  chapter  is  to  describe  the  procedures  followed  in 
constructing  a  Q-GERT  network  simulation  model  of  the  J— 52  intermediate  level 
repair  cycle.  Two  major  phases  characterized  the  work:  performing  an  analysis 
of  the  J— 52  repair  system  and  constructing  the  network  model. 

System  Analysis 

The  system  analysis  phase  was  guided  mainly  by  the  decision-centered 
approach  (22:167)  which  dictates  that  the  development  of  a  management 
decision-making  tool  requires  a  thorough  analysis  of  the  problem  situation  in 
order  to  understand  exactly  which  decisions  the  model  is  required  to  support. 
For  this  research  project,  the  system  analysis  phase  drew  heavily  upon  three 
sources  of  information: 

-  Personal  interviews  with  engine  program  managers, 

-  An  on-site  visit  to  an  intermediate  level  repair  facility, 
and 

-  Personal  experience. 

To  assist  in  carrying  out  the  system  analysis  phase,  a  field  trip  was 
scheduled  to  the  engine  headquarter  offices  in  Washington,  D.C.,  and  to  the 
Propulsion  Branch  of  the  Aircraft  Intermediate  Maintenance  Department  at 
Naval  Air  Station,  Oceana,  Virginia.  (The  facility  at  NAS  Oceana  is  a 
first-degree  repair  facility  in  support  of  several  squadrons  using  the  J  —52 
engine.  This  facility  was  not  modeled;  rather,  it  simply  served  as  a  guide  for 


answering  general  questions  as  the  construction  of  the  generic  model 
progressed). 


The  purpose  of  the  interviews  with  engine  program  managers  was  twofold. 
The  first  related  to  the  output  performance  measure  being  examined  by  the 
model.  Since  turnaround  time  (TAT)  was  of  primary  interest  in  this  project, 
information  was  needed  on  the  standards  for  this  performance  measure  as 
identified  by  engine  program  directives.  The  intent,  therefore,  was  to  identify 
the  appropriate  directives  which  provided  this  information. 

The  second  purpose  of  the  interviews  was  to  discuss  the  operation  of  the 
J  —52  repair  system  in  general.  The  model  treats  the  repair  system  in  simple 
terms  by  imposing  several  limitations  and  by  making  some  assumptions.  Through 
interviews,  a  determination  was  made  as  to  whether  these  limitations  and 
assumptions  were  adequate.  Also,  the  interviews  served  as  a  means  of 
identifying  any  peculiar  characteristics  of  the  repair  system  which  should  be 
included  in  the  model. 

Having  conducted  the  interviews,  the  next  step  in  the  system  analysis 
phase  was  an  actual  on-site  visit  to  an  intermediate  level  engine  repair  facility. 
The  actual  repair  process  was  observed  in  order  to  acquire  specific  information 
about  the  stages  of  repair.  Other  elements  in  the  complete  repair  cycle  pipeline 
were  also  identified.  These  elements  have  been  identified  as  storage  time, 
transit  time  between  facilities,  QEC  romoval/installation,  teardown,  repair, 
awaiting  parts  and  awaiting  maintenance  time,  build-up,  and  test-cell  operation. 
Pritsker  (31:2)  states  "The  success  of  a  modeler  depends  on  how  well  he  can 
define  significant  elements  and  the  relationships  between  elements." 

Therefore,  through  direct  observation,  interviews  with  propulsion  branch 
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managers,  and  personal  experience,  these  elements  and  their  interrelationships 
were  examined.  In  essence,  the  goal  of  this  stage  was  to  "walk  through"  the 
repair  cycle  and  construct  a  prescriptive  model  of  the  J  —52  repair  cycle. 


Model  Construction 


The  final  phase  of  this  project  was  the  construction  of  a  model  of  the 
J— 52  repair  cycle  pipeline  based  on  information  collected  from  the  system 
analysis.  The  Q-GERT  symbology  (described  in  Appendix  H)  was  employed  and 
assigned  to  the  appropriate  points  on  the  network  model. 

Validation  of  the  model  was  not  performed  in  this  project  (validation  is 
discussed  in  Chapter  V  as  a  recommendation  for  follow-on  research).  The 
model's  performance  was,  however,  verified.  Verification  refers  to  the  actual 
running  of  the  simulation  model  on  the  computer  to  verify  that  it  does,  in  fact, 
produce  output.  To  accomplish  this,  it  was  necessary  to  estimate  the 
distribution  functions  employed  at  various  points  in  the  network.  Branching 
probabilities  were  also  estimated.  Inasmuch  as  possible,  personal  intuition  and 


IV.  System  Analysis  and  Model  Construction 


Chapter  Qvervlev 

The  purpose  of  this  chapter  is  to  describe  the  construction  of  the  Q-GERT 
network  model  of  the  U.S.  Navy's  intermediate  level  J— 52  repair  system.  First,  a 
system  analysis  is  provided  in  order  to  describe  the  repair  system  under 
investigation.  While  a  flowchart  of  the  decision  process  was  provided  in  Chapter 
II,  the  system  analysis  in  this  chapter  provides  a  more  in-depth  look  at  the 
characteristics  of  the  repair  system.  This  analysis  provides  the  setting  for  the 
actual  construction  of  the  network  simulation  model. 

Following  the  system  analysis,  the  model  itself,  shown  in  Figure  4,  is 
described  in  detail.  Although  the  operation  of  the  intermediate  level  repair 
system  is  generally  the  same  regardless  of  location,  subtle  differences  do  occur 
in  local  operating  procedures  and  organizational  structure.  For  this  reason,  it  is 
necessary  to  formulate  a  scenario  which  describes  some  of  the  operating  and 
structural  characteristics  of  the  system  being  modeled.  The  contrived  system 
described  in  the  scenario  is  not  based  on  any  particular  existing  facility.  It 
simply  provides  a  setting  in  which  the  model  development  can  take  place.  The 
essential  decisions  and  processes,  however,  are  preserved  in  the  generic  model 
without  loss  of  accuracy. 

One  final  note  is  necessary  to  assist  the  reader  in  understanding  the 
network  model  in  Figure  4.  The  model  spans  six  pages,  and  connectors  are 
provided  to  enable  the  reader  to  trace  the  network  from  page  to  page  without 
loss  of  direction.  These  connectors,  which  are  the  encircled  letters,  serve  only 
as  guideposts  for  the  reader,  and  not  as  nodes  in  the  network. 
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Figure  4.  (Continued) 


System  Analysis 


This  section  describes  the  composition  and  operation  of  the  J-52 
intermediate  level  repair  system  in  a  generic  sense.  An  on-site  visit  to  a  first 
degree  repair  facility  as  described  in  Chapter  Ill  provided  the  background  for 
this  analysis.  Interviews,  direct  observation,  and  personal  experience  are  the 
source  of  all  information  presented  in  this  section. 


Organizational  Composition.  The  typical  first  degree  repair  facility 
employs  approximately  100  personnel,  including  mechanics,  supervisors, 
managers,  and  admisistrative  support  personnel.  Generally,  the  workforce  is 
divided  into  three  8-hour  shifts  and  operates  five  days  a  week.  On  weekends, 
only  a  small  duty  section  performs  repair  services. 

Certain  resources  are  essential  to  the  performance  of  jet  engine  repair. 
These  fall  mainly  under  the  headings  of  crews  and  equipment.  While  slight 
differences  in  crew  composition  may  occur  from  one  facility  to  the  next,  a 
typical  facility  may  include  QEC  (Quick  Engine  Change)  component  removal  and 
build-up  crews,  repair  crews,  and  test  cell  crews.  Repair  crews  may  even  be 
sub-divided  further  by  engine  model. 

The  main  equipment  resources  necessary  for  engine  maintenance  are 
workstands  and  test  cells.  Workstands  include  those  necessary  for  QEC 
component  removal  and  build-up  as  well  as  for  actual  repair.  Generally,  the 
QEC  and  repair  sections  of  the  facility  are  physically  segregated  as  a  result  of 
the  nature  of  the  work  involved.  Test  cells  can  be  of  the  permanent  or  mobile 
type.  First  degree  facilities  generally  utilize  the  permanent,  concrete  test  cells. 


Repair  System  Operation.  The  demand  placed  on  the  repair  facility  comes 
from  tvo  sources:  unscheduled  engine  removals  and  scheduled  engine  removals. 
Unscheduled  removals,  also  referred  to  as  premature  failures,  are  those  engines 
which  are  removed  from  the  aircraft  prior  to  the  scheduled  removal  point  as  a 
result  of  some  type  of  failure.  Typical  failures  which  drive  the  unscheduled 
removal  problem  on  the  J— 52  include  oil  leaks,  compressor  stalls,  internal 
component  failures,  POD  (Foreign  Object  Damage),  vibrations,  gearbox  failures, 
and  metal  contamination.  In  fact,  a  recent  report  issued  by  the  Commander, 
Naval  Air  Force,  Atlantic  Fleet,  (COMNAVAIRLAT),  stated  that  over  60%  of  all 
non-FOD  related  J-52  removals  in  FY-83/84  were  due  to  some  type  of 
premature  failure. 

Scheduled  engine  removals  are  those  engines  removed  from  the  aircraft 
after  reaching  a  specified  number  of  operating  hours  for  the  purpose  of 
undergoing  a  Hot  Section  Inspection  (HS1).  In  a  Hot  Section  Inspection,  certain 
critical  components  in  the  combustion  chamber  and  exhaust  section  are 
inspected  for  damage  and  repaired  or  replaced  as  necessary.  HSI's  are  scheduled 
to  occur  every  750  operating  hours.  As  indicated  previously,  less  than  40%  of 
the  J-52's  in  service  in  FY  83/84  reached  this  point  without  some  type  of 
premature  failure. 

Having  been  removed  from  the  aircraft,  the  engine  is  transported  to  the 
Supply  Support  Center  (SSC)  for  tum-in.  Upon  completion  of  the  necessary 
documentation,  SSC  coordinates  the  induction  of  the  retrograde  engine  into  the 
IMA  for  repair.  It  should  be  noted  here  that  this  coordination  step  does  not 
always  result  in  the  induction  of  an  engine  into  a  "local"  IMA.  For  bases  with 
second  or  third  degree  facilities,  the  engine  will  require  transportation  to  a 
facility  with  higher  level  repair  capability  if  the  extent  of  repair  is  determined 
to  be  beyond  the  capability  of  the  local  IMA. 


Upon  arrival  at  the  repair  facility,  the  engine  undergoes  administrative 
processing.  This  includes  not  only  preparing  the  necessary  paperwork  for  control 
of  the  repair  process,  but  also  a  logbook  screening  process.  The  engine  logbook 
is  a  binder  which  contains  historical  information  pertaining  to  the  engine's 
operating  history  and  physical  configuration.  The  purpose  of  the  screening 
process  is  to  identify  any  additional  discrepancies  which  can  be  resolved  during 
the  repair,  as  well  as  to  identify  those  engine  components  which  are  near  their 
high-time  removal  point. 

The  objective  of  the  logbook  screening  process  (at  a  first  degree  site)  is  to 
decide  whether  to  repair  the  engine  locally  or  forward  it  to  a  depot  facility  for 
in-depth  repair.  This  decision  is  largely  subjective  and  is  generally  based  on 
factors  such  as  the  number  of  available  operating  hours  remaining  to  the  HSI, 
the  number  of  components  within  their  high-time  removal  envolope,  and/or  the 
possible  requirement  for  an  Engineering  Investigation  (El).  Also,  in  some  cases, 
upper  echelon  management  will  intervene  and  direct  the  flow  of  engines  for 
repair  at  certain  facilities  to  balance  the  workload. 

Upon  completion  of  the  logbook  screening  process,  the  engine  normally 
undergoes  a  pre-induction  test  cell  run.  This  is  a  further  attempt  to  identify 
discrepancies  which  can  be  reapired  while  at  the  IMA.  A  test  cell  crew  is 
assigned  to  the  task  and  prepares  the  engine  for  the  test  cell  run.  This  involves 
the  installation  of  certain  equipment  on  the  engine  in  order  to  facilitate 
controlling  the  engine  during  the  run  as  well  as  monitoring  engine  performance. 

Once  the  test  cell  run  is  complete,  supervisory  and  management  personnel 
review  the  engine's  performance,  and  a  determination  is  made  as  to  the  extent 
of  the  repair  that  is  necessary.  A  minor  repair  is  one  which  can  be  performed 
without  a  complete  teardown  of  the  engine.  Normally,  this  could  include  removal 
and  replacement  of  certain  externally  mounted  components  or,  perhaps,  some 


minor  adjustment.  For  such  repairs,  QEC  component  removal  is  not  required. 

A  major  repair  is  one  which  requires  a  substantial  degree  of  teardown  to 
gain  access  to  the  affected  area.  For  this  type  repair,  a  QEC  crew  places  the 
engine  on  a  QEC  workstand  and  removes  all  QEC  components.  These  components 
are  tagged  and  identified  by  serial  number  and  engine  number  to  ensure  no 
mismatch  occurs  between  components,  engines,  and  logbooks. 

Having  completed  QEC  removal  (if  required),  the  engine  transitions  into 
the  repair  phase.  At  this  point,  a  repair  crew  and  repair  workstand  is  assigned. 
Conceivably,  some  repair  sites  may  have  crews  designated  to  work  on  specific 
models  only.  There  may  be,  for  example,  crews  designated  as  J-52-P-6/8  repair 
crews  or  J-52-P-408  repair  crews.  Nevertheless,  a  crew  is  assigned,  as  well  as  a 
workstand. 

During  the  entire  repair  phase  (whether  minor  or  major),  delays  can  occur 
which  result  in  work  stoppage.  Delays  may  occur  while  awaiting  parts  (AWP)  or 
while  awaiting  maintenance  (AWM).  AWP  time  is  self-explanatory.  AWM  time 
can  occur  for  a  number  of  reasons.  For  example,  if  a  special  tool  used  in 
de-coupling  the  turbine  from  the  compressor  breaks  and  requires  repair  before 
the  job  can  continue,  the  delay  encountered  while  repairing  the  tool  is  counted 
as  awaiting  maintenance  (AWM).  In  general,  whether  minor  or  major  repair,  the 
processes  include  the  initial  stage  of  repair  (including  teardown),  delays 
incurred  for  parts  or  other  reasons,  and  the  continuance  and  completion  of 
repair  (including  build-up).  The  average  time  associated  with  each  of  these  may 
differ  significantly. 

Next,  a  determination  is  made  as  to  whether  the  completed  engine  requires 
a  post-maintenance  test  cell  run  to  verify  the  successful  accomplishment  of 
repairs,  in  general,  this  is  a  routine  step,  and  relatively  few  engines  are 
returned  to  use  without  a  test  cell  run.  Again,  the  test  cell  crew  prepares  the 


engine  as  before  and  conducts  the  run.  Some  possibility  does  exist  that  an 
engine  may  be  declared  unserviceable  as  a  result  of  its  test  cell  performance.  If 
so,  the  lingering  discrepancy  is  reviewed,  and  appropriate  actions  are  taken  to 
re-induct  the  engine  for  more  repair. 

Finally,  after  an  engine  has  been  declared  fixed,  preparations  are  made  to 
release  the  engine  back  to  the  Supply  Support  Center  (SSC).  For  major  repairs, 
this  includes  the  re-installation  of  QEC  components  which  were  removed 
originally.  A  QEC  crew  places  the  engine  on  a  QEC  workstand  and  performs  the 
necessary  QEC  build-up.  The  engine  is  then  delivered  back  to  the  SSC  as  an 
RFI  (Ready  for  Issue)  engine. 

Model  Construction 

This  section  describes  the  construction  of  the  Q-GERT  network  simulation 
model  shown  in  Figure  4.  \s  stated  earlier,  subtle  differences  occur  in  the 
composition  and  operation  at  different  facilities.  Therefore,  a  "typical"  scenario 
of  the  system  modeled  in  this  project  is  provided  first.  Following  this,  the 
network  logic  and  symbology  are  described. 

Model  Scenario.  The  hypothetical  repair  system  modeled  in  this  project 
operates  continuously,  24  hours  a  day.  It  provides  repair  services  for  all  three 
models  of  the  J —52:  the  P-6,  P-8,  and  P-408.  No  distinction  is  made  between 
engines  received  from  remote  bases  and  those  received  from  local  operating 
units.  However,  a  distinction  _is  made  between  unscheduled  removals  and 
scheduled  removals  since  different  demand  rates  are  Imposed  by  each. 

The  interarrival  rate  of  engines  at  the  repair  facility  is  exponentially 


distributed,  with  a  mean  of  36  clock  hours  between  unscheduled  removals,  and 
68  clock  hours  between  scheduled  removals.  This  is  based  on  a  forecast  of 
445,000  flight  hours  to  be  flown  by  all  J-52's  in  a  given  year,  1300  engines  in 
operation,  approximately  260  days  of  operation  per  year,  and  200  engines 
supported  by  the  facility.  In  addition,  the  distinction  between  the  two 
interarrival  rates  comes  from  the  fact  that  unscheduled  removals  occur,  on  the 
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average,  at  the  400th  flight  hour,  and  scheduled  removals  occur  at  the  750th 
flight  hour  point. 

The  crews  performing  maintenance  on  the  engine  fall  into  one  of  four 
categories:  test  cell  crew,  QEC  crew,  P-6/8  repair  crew,  and  P-408  repair 
crew.  The  assumption  is  made  that  P-6's  and  P-8's  are  similar  enough  that  the 
same  crew  can  work  on  both  types.  The  P-408,  however,  is  significantly 
advanced  in  design  and  warrants  more  skilled  crews.  The  facility  modeled  in  this 
project  has  two  QEC  crews,  two  test  cell  crews,  ten  P-6/8  repair  crews,  and 
two  P-408  repair  crews.  (Some  facilities  have  chosen  not  to  have  separate 
crews  for  QEC  removal  and  installation). 

The  repair  facility  has  separate  workstands  designated  for  either  QEC  or 
repair.  Four  QEC  workstands  are  available,  and  sixteen  repair  workstands  are 
available.  In  addition,  the  facility  has  two  permanent  test  cells. 

Model  Description.  As  transactions  flow  through  the  network  of  Figure  4, 
five  attributes  are  assigned  to  the  transactions  to  identify  distinct 
characteristics.  These  attributes  allow  the  modeler  to  attach  identifying 
characteristics  to  each  individual  transaction  flowing  through  the  network.  The 
table  which  follows  describes  the  attributes  used  in  this  model  and  the  values 
possible  for  each  attribute.  The  information  provided  by  these  attributes  is 
useful  in  making  branching  decisions  as  will  be  seen  later  in  the  model. 


1 


Engine  model 


6  (for  P-6) 

8  (for  P-8) 
408  (for  P-408) 


2 

Type  of  removal 

1  (unscheduled) 

2  (scheduled) 

3 

Extent  of  repair 

1  (for  minor) 

2  (for  major) 

4 

Repair  capability 

1  (local  IMA) 

2  (Depot) 

5 

Engine  status 

1  (Non-RFl) 

2  (RF1) 

The  resources  mentioned  earlier  (crews,  workstands. 

and  test  cells)  must 

also  be  tracked  by  the  model.  Resources  are  limited,  and  the  "pace"  of  the 

maintenance  effort  is  constrained 

by  the  availability  of 

these  resources.  For 

this  reason,  resource  numbers  are 

• 

assigned.  The  table  which  follows  shows  the 
• 

resources  employed  in  this  model. 

Resource  # 

Description 

Units  Available 

1 

QEC  crew 

2 

2 

Test  cell  crew 

2 

3 

P-6/8  repair  crew 

10 

4 

P-408  repair  crew 

2 

5 

QEC  works tand 

4 

6 

Repair  workstand 

16 

7 

Test  cell 

2 

V  V  ~- 
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values  to  identify  the  type  of  removal  scheduled  or  unscheduled)  and  the  engine 
status,  respectively. 

Branching  from  node  3  and  from  node  4  establishes  the  percentage  of 
incoming  engines  that  are  P-6,  P-8,  or  P-408.  Accordingly,  nodes  5,  6,  and  7 
assign  the  appropriate  engine  model  identifier  to  attribute  1.  The  branches  from 
nodes  5,  6,  and  7  to  node  9  represent  the  transit  time  to  the  Supply  Support 
Center.  Here,  the  engine  may  incur  some  delay,  but  is  eventually  transported  to 
the  IMA  facility. 

Node  10  is  the  receival  point  at  the  IMA.  Waiting  occurs  here  while  the 
engine  undergoes  administrative  processing,  represented  by  activity  7.  From 
node  11,  the  engine  takes  one  of  two  paths:  to  depot  or  to  the  IMA. 
Approximately  5%  will  require  depot  level  maintenance  which  is  performed  at 
nodes  12  and  13.  The  remaining  95%  are  inducted  for  repair  at  the  IMA. 

From  node  14,  97%  of  the  engines  will  require  a  pre-induction  test  cell 
run.  Nodes  15  through  23  represent  this  activity.  A  test  cell  crew  is  assigned  at 
node  16,  the  engine  is  prepared  for  the  test  cell  at  activity  10,  a  test  cell  is 
assigned  at  node  19,  and  finally,  activity  11  is  the  actual  test  cell  run.  Nodes 
22  and  23  represent,  respectively,  the  release  of  the  test  cell  crew  and  the  test 
cell  upon  completion  of  the  run.  These  resources  are  then  available  for 
re-assignment. 

From  node  24,  95%  of  the  engines  are  categorized  as  major  repair,  5%  as 
minor  repair.  If  the  repair  is  major,  nodes  25  through  33  are  encountered  which 
represent  the  removal  of  the  QEC  components.  A  QEC  crew  is  assigned  at  node 
27  and  a  QEC  workstand  at  node  29.  Activity  12  is  the  removal  of  the  QEC 
components.  Upon  completion  of  the  job,  the  QEC  crew  and  QEC  workstand  are 
freed  up  by  nodes  32  and  33,  respectively.  If  the  repair  is  categorized  as  minor, 
activity  36  is  encountered,  signifying  that  QEC  removal  is  not  required. 
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Regardless  of  the  path  taken  from  node  24,  the  appropriate  extent-of-repair 
designator  is  assigned  to  attribute  3  at  node  25  or  node  26. 

Node  34  marks  the  beginning  of  the  actual  repair  phase  for  the  engine.  The 
conditional  branching  from  this  node  accounts  for  the  different  engine  models. 
If  attribute  1  (engine  model)  is  6  or  8,  then  the  transaction  follows  activity  37 
or  36  to  node  35  where  it  waits  for  the  assignment  of  a  P-6/8  repair  crew  by 
node  36.  Similar  reasoning  is  applied  to  activity  39  as  well  for  the  P-408.  In 
both  cases,  waiting  may  then  occur  at  node  39  until  a  workstand  is  assigned  at 
node  40. 

The  conditional  branching  from  node  41  to  node  42  represents  the  initial 
stages  of  repair  in  accordance  with  the  extent-of-repair  attribute.  Major  repairs 
incur  a  time  associated  with  activity  13,  while  minor  repairs  incur  a  time 
associated  with  activity  14. 

Next,  probabilistic  branching  from  node  42  occurs  in  accordance  with  the 
probabilities  associated  with  experiencing  delays.  These  may  be  due  to  AWP 
(activity  40)  or  AWM  (activity  41).  It  may  also  be  possible  to  experience  no 
delay  (activity  42).  The  duration  of  a  time  delay  depends  upon  the  extent  of 
repair.  Major  repairs  experience  a  much  longer  delay  than  minor  repairs. 
Accordingly,  the  branching  at  node  44  checks  the  extent-of-repair  attribute  and 
routes  the  transaction  along  the  appropriate  branch.  A  similar  logic  is  applied 
at  node  54  for  AWM. 

If  a  delay  is  experienced  (either  AWP  or  AWM),  a  duplicate  transaction  is 
sent  to  node  50.  At  this  point,  a  check  is  made  to  determine  the  engine  model 
as  indicated  by  the  conditional  branching  from  node  50.  If  the  engine  is  a  P-6 
or  P-8,  then  the  repair  crew  is  freed  up  by  node  51  and  made  available  for 
reassignment  at  the  nodes  indicated  in  the  box  below  node  51.  Similarly,  node 
52  releases  the  P-408  repair  crew.  This  entire  portion  of  the  network  is 
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employed  to  simulate  the  fact  that  repair  crews  do  not  remain  idle  the  entire 
time  the  engine  is  experiencing  AWP  or  AWM  delays. 

Upon  expiration  of  the  delay,  the  engine  is  ready  to  resume  its  repair 
phase.  Nodes  45  (for  expiration  of  AWP)  and  55  (for  expiration  of  AWM)  provide 
conditional  branching  once  again  to  determine  the  engine  model.  This  step  is 
necessary  in  order  to  re-allocate  the  proper  repair  crew  to  the  engine.  For 
engines  coming  out  of  AWP  status,  node  47  assigns  a  P-6/8  repair  crew,  or  node 
49  assigns  a  P-408  repair  crew,  whichever  is  appropriate.  A  similar  resource 
allocation  scheme  takes  place  at  nodes  57  and  59  for  engines  coming  out  of 
AWM  status. 

The  branching  from  node  60  to  61,  and  from  61  to  62  represents  the 
completion  of  repair  and  build-up  phase  for  engines  in  a  major  repair  status. 
Activity  21  from  node  60  to  62  represents  the  completion  of  repair  for  engines 
in  a  minor  repair  status.  Having  completed  repair,  the  repair  crews  are  then 
released.  From  node  62,  a  check  is  made  to  determine  the  engine  model  by 
examining  attribute  1.  If  the  engine  is  a  P-6  or  P-8,  node  63  releases  that  type 
of  repair  crew  and  makes  them  available  for  re-allocation  at  the  nodes  in  the 
box  below  node  63.  Node  64  releases  a  P-408  repair  crew  in  a  similar  manner. 

Having  completed  the  repair  phase,  95%  of  the  engines  require  a 
post-maintenance  test  cell  run  as  indicated  by  the  branch  emanating  from  node 
66  labeled  as  activity  55.  Nodes  67  through  75  represent  this  activity.  A  test 
cell  crew  is  allocated  at  node  68,  the  engine  is  prepared  for  the  test  cell  in 

activity  22,  a  test  cell  is  allocated  at  node  71,  and  the  test  cell  run  is  made  at 

activity  23.  As  with  all  other  processes,  the  resources  are  freed  up  at  the 
completion  of  the  task.  Node  74  releases  the  test  cell  crew,  and  node  75 

releases  the  test  cell.  Both  of  these  resources  are  made  available  for 

reassignment  at  the  nodes  indicated  in  the  box  below  the  free  nodes. 


Approximately  5%  of  the  engines  coming  off  the  test  cell  have  lingering 
discrepancies  and  require  further  maintenance.  If  so,  these  transactions  are 
routed  to  node  85.  Of  these,  95%  are  designated  as  minor  repair  and  5%  as 
major  repair  (attribute  3).  The  transaction  is  routed  back  to  node  34  where  it 
re-enters  the  repair  process. 

Transactions  along  activity  58  from  node  75  to  89  represent  engines  with  a 
successful  test  cell  run.  Conditional  branching  at  node  89  checks  to  see  if  the 
repair  was  a  major  or  minor  repair.  If  it  was  major,  the  branch  to  node  76  is 
taken.  Nodes  76  through  83  represent  the  QEC  build-up  phase.  (Recall  that  only 
major  repairs  had  the  QEC  components  removed).  Nodes  82  and  83  release  the 
QEC  crew  and  QEC  workstand,  respectively. 

Finally,  the  engine  is  ready  to  be  released  back  to  the  Supply  Support 
Center  for  subsequent  issue  to  fill  a  demand  as  required.  Nodes  81  and  90  both 
designate  the  engine  as  RF1  (Ready  For  Issue)  by  assigning  a  value  of  2  to 
attribute  5.  Activity  25  from  node  83  to  84  and  activity  63  from  node  90  to  84* 
both  represent  the  time  in  transit  back  to  the  SSC.  At  node  84  the  transaction 
departs  the  system  signifying  the  completion  of  the  pipeline. 

Care  was  taken  in  the  development  of  the  model  to  ensure  that  repair 
processes  associated  with  minor  and  major  repair  were  distinguished  since  their 
corresponding  times  are  significantly  different.  Table  I  on  the  following  page 
provides  a  listing  of  all  activities  identified  in  the  model  along  with  the 
statistical  distribution  employed,  and  estimates  of  the  mean,  minimum,  maximum, 
and  standard  deviation  values  of  each  activity. 

This  completes  the  general  description  of  the  network  model  of  the  J  —52 
intermediate  level  repair  system.  Before  concluding  the  discussion,  however, 
some  minor  points  about  the  model  are  discussed  in  order  to  clarify  certain 
aspects  of  the  symbology  employed. 


Table  l 


Activity  Times  (in  hours) 


Statistical 


Activity 

Distribution 

Mean 

Min. 

Max. 

Dev. 

Interarrival  rate 

Exponential 

36.0 

0.0 

120.0 

(unsched.  removals) 
Interarrival  rate 

Exponential 

68.0 

0.0 

240.0 

(sched.  removals) 
Transit  to  SSC 

Lognormal 

6o.O 

0.0 

240.0 

20.0 

Transit  to  IMA 

Normal 

2.0 

1.0 

3.0 

0.5 

Admin,  processing 

Normal 

48.0 

10.0 

72.0 

12.0 

Transit  to  depot 

Normal 

120.0 

48.0 

240.0 

24.0 

Repair  at  depot 

Lognormal 

456.0 

288.0 

624.0 

60.0 

Prepare  engine  for  pre¬ 
induction  test  cell  run 

Lognormal 

3.0 

1.0 

6.0 

1.0 

Perform  pre-induction 
test  cell  run 

Lognormal 

4.0 

2.0 

16.0 

0.5 

QEC  removal 

Normal 

3.0 

2.0 

5.0 

0.5 

Teardown  (major  repair) 

Lognormal 

48.0 

36.0 

96.0 

6.0 

Initial  stage  of  minor 
repair 

Lognormal 

12.0 

2.0 

36.0 

6.0 

AWP  for  major  repair 

Lognormal 

360.0 

0.0 

3168.0 

48.0 

AWP  for  minor  repair 

Lognormal 

24.0 

0.0 

48.0 

6.0 

AWM  for  major  repair 

Lognormal 

48.0 

0.0 

96.0 

12.0 

AWM  for  minor  repair 

Lognormal 

12.0 

0.0 

36.0 

6.0 

Repair  phase  of  major 
repair 

Lognormal 

168.0 

48.0 

336.0 

48.0 

Build-up  phase  of 
major  repair 

Lognormal 

240.0 

144.0 

360.0 

48.0 

Completion  of  minor  repair 

Lognormal 

24.0 

6.0 

48.0 

8.0 

Prepare  engine  for  post- 
maint.  test  cell  run 

Lognormal 

3.0 

1.0 

6.0 

1.0 

Perform  post-maint. 
test  cell  run 

Lognormal 

4.0 

2.0 

16.0 

0.5 

QEC  build-up 

Normal 

8.0 

4.0 

16.0 

1.0 

Transit  back  to  user 

Normal 

60.0 

0.0 

240.0 

20.0 

Note  that  queue  capacities  are  treated  as  infinite  on  ail  queues  in  the 
network.  This  implies  that  ample  "waiting"  space  is  available  for  engines  in  each 
stage  of  the  pipeline,  and  that  the  repair  process  is  not  halted  for  lack  of 
waiting  room.  In  other  words,  there  is  always  ample  space  for  engines  to 
accumulate  at  any  particular  point  in  the  cycle. 

In  reality,  this  feature  may  not  always  be  a  feasible  assumption. 

Floorspace  limitations  and  building  designs  may  place  constraints  on  the  ability 

to  accumulate  engines  at  some  facilities.  Generally,  waiting  space  for  engine 

accumulations  at  shore-based  facilities  does  not  present  a  problem.  Waiting 
space  at  carrier-based  facilities,  however,  presents  a  problem  of  some 
magnitude  and  must  be  considered  carefully. 

In  such  cases,  the  modeler  may  want  to  include  blocking  symbols  on  the 
network  as  a  means  of  dealing  with  this  constraint.  (Blocking  is  explained  in 
Appendix  H).  Using  this  feature  enables  the  modeler  to  "halt  the  action 
upstream"  should  a  transaction  attempt  to  join  a  queue  which  is  already  full. 
When  space  opens  up  in  the  queue,  Q-GERT  automatically  resumes  the  activity 
and  allows  the  transaction  to  join  the  queue. 

Note  also  that  interval  statistics  nodes  are  present  throughout  the 

network.  These  were  incorporated  to  demonstrate  the  ease  with  which 
incremental  pipeline  times  can  be  determined.  The  time  an  engine  enters  the 
pipeline  is  established  at  the  source  nodes  (nodes  1  and  2),  and  is  tracked  on 
each  transaction  throughout  its  trek  in  the  pipeline.  Statistics  nodes  can  be 
inserted  at  almost  any  point  in  the  network  where  it  is  desired  to  obtain  a  time 
reading. 

The  tracking  of  time  on  each  transaction  is  also  significant.  It  should  be 
pointed  out  here  that  the  model  is  constructed  so  as  to  allow  1000  hours  of 
"simulated  time"  to  pass  before  statistics  are  collected.  This  was  an  arbitrary 


choice  of  "warm-up"  time  for  allowing  the  system  to  reach  a  fairly  steady  state 
operation  before  collecting  statistics.  In  other  words,  the  queues  (the  entire 
system  for  that  matter)  are  empty  at  the  start  of  the  run,  and  the  1000  hours 
of  initial  warm-up  time  allow  the  system  to  become  filled  with  transactions  at  a 
level  approximating  steady  state  in  order  to  improve  the  accuracy  of  the 
statistics  collected. 

All  information  contained  on  the  model  in  Figure  4  has  been  converted  to 
computer  input  code  which  is  acceptable  to  the  Q-GERT  Analysis  Program.  The 
Q-GERT  Analysis  Program  is  the  software  which  is  responsible  for  translating 
the  input  code  into  computer  understandable  language  and  performing  the 
simulation.  Appendix  1  contains  the  input  code  for  the  model  constructed  in  this 


V.  Conclusion 


Chapter  Overview 

The  simulation  model  developed  in  Chapter  IV  (Figure  4)  represents  the 
culmination  of  the  research  effort  of  this  thesis  project.  This  chapter  now  takes 
a  macro  view  of  the  model  and  analyzes  some  of  its  characteristics.  First,  a 
general  discussion  on  the  results  of  the  model  development  is  presented.  In  this 
section,  the  output  results  from  an  actual  computer  run  of  the  model  are 
described,  as  well  as  some  inherent  shortcomings  and  limitations  of  the  model. 
Second,  its  use  as  a  management  tool  is  discussed  in  light  of  the  research 
problem.  Finally,  some  recommendations  for  follow-on  research  in  this  area  are 
discussed. 


Results  of  the  Model  Devolopment 

The  development  of  the  model  in  Figure  4  is  certainly  a  major  step  closer 
to  investigating  pipeline  delays  and  backlog  problems  in  the  Navy’s  J-52  repair 
system.  However,  management  is  primarily  interested  in  output  results  as  an  aid 
to  decision  making.  For  this  reason,  a  discussion  of  the  results  of  the 
development  effort  is  presented  in  this  section. 


Output  of  the  Model,  Recall  that  not  only  was  the  graphical  Q-GERT 
model  presented  in  Chapter  IV,  but  also  the  corresponding  computer  source  code 
was  provided  in  Appendix  l.  Furthermore,  this  source  code  was  centered  around 
the  hypothetical  scenario  described  in  Chapter  IV.  The  reason  for  including  this 


source  code  was  to  be  able  to  actually  test  the  model  and  verify  its  operation. 
This  is  not  to  be  confused  with  validation  of  the  model,  but  simply  an  effort  to 
"de-bug"  or  verify  the  operation  of  the  model,  and  to  demonstrate  an 
interpretation  of  the  output. 

The  source  code  was,  in  fact,  verified  on  the  Cyber  computer  at 
Aeronautical  Systems  Division  at  Wright-Patterson  Air  Force  Base  in  Dayton, 
Ohio.  The  output  data  from  the  computer  run  is  discussed  in  this  section  in 
otder  to  acquaint  the  reader  with  how  to  interpret  the  results,  as  well  as  the 
usefulness  of  the  model.  In  view  of  the  size  of  the  printout  and  the 

"readability"  of  the  type,  the  printout  was  unsuitable  for  reproduction  and 

inclusion  in  this  report.  However,  essential  data  was  extracted  from  the  printout 
and  put  in  tabular  form  in  order  for  the  reader  to  view  the  results.  Tables  11 

through  VI  at  the  end  of  this  chapter  contain  this  essential  data  from  the 

printout. 

The  first  table  of  output  information  provided  by  the  Q-GERT  Analysis 
Program  relates  to  the  average  amount  of  time  transactions  took  to  reach 
certain  nodes.  In  terms  of  the  J— 52  repair  system,  these  node  statistics  refer  to 
the  average  amount  of  time  J— 52  engines  took  to  reach  various  points  in  the 
repair  cycle  pipeline.  Table  II  shows  a  summary  of  the  results,  with  the  nodes 
listed  sequentially. 

Referring  to  Table  II,  for  example,  the  average  amount  of  time  an  engine 
spends  in  the  complete  pipeline  is  found  at  node  84.  At  this  node  it  can  be  seen 
that  the  average  pipeline  time  over  the  course  of  the  simulation  was 
approximately  2644  hours,  or  110  workdays.  The  two  columns  on  the  far  right 
side  reveal  that  the  minimum  amount  of  time  observed  by  an  engine  in  the 
complete  pipeline  was  about  2341  hours,  or  97  workdays,  while  the  maximum 
pipeline  time  was  observed  to  be  about  2913  hours,  or  121  workdays. 


The  average  time  spent  in  any  given  portion  of  the  pipeline  can  also  be 
found  by  subtracting  the  smaller  value  from  the  larger  value  between  two  nodes 
since  the  nodes  are  listed  sequentially  and  all  times  start  at  the  same  point.  For 
example,  an  estimate  of  the  average  amount  of  time  an  engine  undergoing  major 
repair  spends  in  the  actual  repair  phase  (excluding  test  cell  runs  and  QEC  work) 
can  be  found  by  subtracting  the  node  31  average  time  from  the  node  69  average 
time.  The  result  is  approximately  2217  hours,  or  92  workdays,  and  includes 
delays  associated  with  waiting  for  crew  and  workstand  assignments,  as  well  as 
AWP  and  AWM  time. 

Tables  111  and  IV  would  be  perhaps  the  most  useful  to  managers  interested 
in  delays  and  backlogs  in  the  pipeline.  These  two  tables  contain  information  on 
Q-nodes  which  is  where  waiting  occurs  in  the  network.  Referring  to  Table  IH,  it 
can  be  seen  that  the  average  amount  of  waiting  time  experienced  at  each  queue 
in  the  system  can  be  determined.  At  Q-node  35,  for  example,  approximately 
1719  hours  of  delay  is  incurred  by  the  P-6's  and  P-8's  awaiting  repair  crew 
assignment  and  workstand  assignment.  Additionally,  at  one  point  in  the 
simulation,  a  maximum  of  133  engines  were  observed  to  be  waiting  at  this 
queue.  Table  IV  shows  that  the  average  number  of  engines  waiting  at  Q-node  35 
was  about  58.  Although  these  figures  are  highly  unrealistic,  it  must  be 
remembered  that  the  results  are  based  on  contrived  parameters  and  a 
hypothetical  scenario.  They  are  included  here  to  illustrate  the  type  of 
information  available  to  managers  dealing  with  limited  resources. 

Tables  V  and  VI  provide  information  on  resources  employed  in  the 
simulation  (crews,  workstands,  test  cells).  These  tables  are  actually  compliments 
of  each  other  since  one  gives  information  on  the  average  number  of  units  of  a 
certain  resource  employed  (utilization),  while  the  other  gives  information  on  the 
average  number  of  resource  units  uncommitted  or  unassigned  (availability). 


Referring  to  Table  V  it  can  be  seen  that  the  average  number  of  units  of 
resource  # 2  utilized  was  approximately  0.39,  with  an  average  availability  of 
approximately  1.60  from  Table  VI.  In  other  words,  at  least  one  test  cell  crew 
was  idle  over  80%  of  the  time. 

Similarly,  out  of  the  10  available  P-6,8  repair  crews  (resource  #3),  Table  V 
shows  that  the  average  number  of  crews  utilized  continuously  was  10,  with  an 
average  availability  of  0.0  from  Table  VI.  In  other  words,  the  results  clearly 
indicate  that  P-6  and  P-8  repair  crews  are  continously  employed,  represeting  a 
potentially  scarce  resource. 

Shortcomings  of  the  Model.  One  of  the  goals  of ‘simulation  modelers  is  to 
replicate  as  closely  as  possible  the  real  system  to  avoid  losing  too  much 
accuracy.  The  near  impossibility  of  reaching  a  100%  correspondence  with  the 
real  system  gives  rise  to  shortcomings  and  limitations  with  which  the  modeler 
must  contend.  A  few  of  the  shortcomings  of  this  model  are  discussed  here. 

The  J— 52  repair  cycle  is  a  complex  system  to  model.  To  do  greater  justice 
to  the  system,  more  nodes  and  branches  are  needed  to  account  for  additional 
on-going  activities  not  included  in  this  model.  The  level  of  detail  presented  in 
this  model,  however,  w as  constrained  by  the  limitations  of  the  Q-GERT  Analysis 
Program,  which  places  an  upper  limit  of  100  on  the  maximum  number  of  nodes 
which  may  be  placed  in  the  network.  Although  it  has  not  been  confirmed,  the 
author  understands  that  larger  versions  of  the  Q-GERT  Analysis  Program  may 
be  available  which  can  accomodate  a  significantly  greater  number  of  nodes  in 
the  network.  If  this  larger  version  of  Q-GERT  does,  in  fact,  exists,  its  use 
should  be  investigated. 

To  simplify  construction  of  the  model  and  to  present  the  model  only  as  a 
concept  to  spark  further  work,  certain  assumptions  were  made  regarding  Q-node 


conditions  that  represent  shortcomings  inherent  in  the  model.  Queues  represent 
waiting  areas,  and  waiting  areas  do  not  always  enjoy  the  luxury  of  having  an 
infinite  amount  of  space.  Nevertheless,  infinite  queue  capacities  were  specified 
on  all  Q-nodes. 

To  restrict  queue  capacities  would  require  extra  consideration  to  be  given 
to  the  possibility  of  transactions  arriving  at  a  queue  which  is  full.  If  not  dealt 
with  properly,  this  situation  can  result  in  transactions  "disappearing"  from  the 
system.  Blocking  or  balking  are  two  possibilities  for  coping  with  this  problem. 
However,  in  this  particular  model,  the  network  maximum  nodal  limitations  would 
have  been  exceeded. 

The  final  limitation  discussed  here  relates  also  to  Q-nodes.  At  the  start-up 
of  the  system,  it  is  desirable  to  have  transactions  already  in  the  system  to 
represent  the  system  at  steady  state  operation.  Failure  to  do  so  implies  that  the 
system  must  "start  from  scratch"  and  feed  transactions  into  the  system  for  a 
certain  period  of  time  before  it  reaches  a  relatively  steady  state. 

The  model  in  this  project  did  not  incorporate  initial  transactions  in  the 
queues  because  of  problems  encountered  with  attribute  assignments  for 
conditions’  branching.  On  a  trial  run,  transactions  were  placed  in  all  queues 
initially.  As  the  simulation  progressed,  it  was  noted  that  these  transactions 
never  left  the  queues  because  they  had  no  attribute  values  assigned  to 
accomodate  conditional  branching.  Thus  the  simulation  was  halted  by  these 
"stalled"  transactions. 

Two  methods  for  overcoming  this  are  the  use  of  FORTRAN  inserts  and  the 
provision  of  a  "warm-up"  time.  FORTRAN  inserts  are  discussed  by  Pritsker 
(31:235-296)  and  are  a  means  of  using  sub-routines  to  accomplish  this  task.  To 
avoid  additional  complexity,  however,  the  latter  approach  was  taken  which, 
according  to  the  output  data,  came  very  near  to  replicating  steady  state 


\  *S- 


conditions.  A  1000  hour  warm-up  period  was  used  to  achieve  steady  state 
conditions  before  collecting  statistics. 


The  Model  as  a  Management  Tool 


As  stated  in  Chapter  1,  the  original  purpose  in  the  development  of  this 
model  was  to  offer  an  approach  to  examining  pipeline  problems  in  the  Navy’s 
J-52  repair  system.  It  does  not  specifically  address  any  particular  issue  but 
offers  management  an  approach  to  investigating  two  key  issues  -  pipeline 
backlogs  and  resource  utilization.  With  a  fair  amount  of  creativity,  managers 
can  experiment  with  a  number  of  repair  system  design  structures  or.  resource 
utilization  schemes  in  order  to  help  pinpoint  different  ways  of  making  the 
system  operate  more  efficiently  and  more  effectively. 

Repair  site  consolidation  was  mentioned  in  Chapter  1  as  one  approach  the 
Navy  is  considering  as  a  solution  to  some  of  the  pipeline  problems  it  is 
experiencing.  The  validity  of  this  approach  has  rot  been  established,  nor  is  it 
within  the  scope  of  this  report  to  offer  a  judgement  on  it.  Given,  however,  that 
consolidation  of  facilities  is  pursued  by  the  Navy,  it  will  become  necessary  to 
establish  some  criterion  by  which  management  will  decide  which  facilities  are 
candidates  for  consolidation.  The  contention  of  the  author  is  that  the  Q-GERT 
simulation  model  may  be  helpful  in  this  area.  If  the  established  crit-Jon  relates 
to  backlog  delays  or  resource  utilization,  then  the  model  could  be  used  to 
compare  the  operation  of  like  facilities  and  to  determine,  perhaps,  the  most  (or 
least)  efficient  or  effective  facility  among  those  compared.  Such  a  comparison 
may  assist  management  in  deciding  upon  a  consolidation  plan. 

Minimizing  flow  time  through  the  pipeline  can  also  be  achieved  by 


optimizing  the  number  of  resources  at  each  facility.  By  using  the  model  output, 
management  can  identify  those  resources  with  a  high  percentage  of  idle  time. 
These  resources  then  could  possibly  be  reallocated  to  other  facilities  where  the 
same  resource  is  scarce. 

Recommendations  for  Further  Research 

Simulation  models,  by  their  very  nature,  are  approximations  of  real  world 
systems.  Because  of  this,  there  is  always  room  for  improvement  in  the  model  to 
achieve  greater  accuracy.  This  section  provides  a  short  discussion  on  areas 
recommended  for  follow-on  research  in  order  to  expand  the  usefulness  of  the 
model. 

Various  Q-GERT  network  designs  should  be  tested.  The  Q-GERT  model  in 
this  project  is  not  the  only  alternative  for  investigating  the  J-52  repair  system, 
only  the  first  attempt.  Other  arrangements  of  the  network  should  be  tested  to 
attempt  a  more  efficient  design.  Care  should  be  exercised,  however,  to  insure 
that  modifications  to  the  model  do  not  simply  add  to  its  complexity  without  a 
significant  increase  in  accuracy. 

Probably  the  most  important  step  to  be  undertaken  next,  however,  is 
validation  of  the  model.  This  step  requires  an  extensive  statistical  analysis  of 
the  parameters  in  the  network  in  order  to  obtain  the  correct  statistical 
distributions  for  the  various  processes  taking  place.  The  goal  is  to  achieve 
output  results  similar  to  actual  performance  of  the  real  world  system.  Follow-on 
researchers  should  not  attempt  any  comparison  of  facilities  for  the  purpose  of 
measuring  efficiency  or  effectiveness  until  a  validation  has  been  accomplished. 
This  will  be  achieved  only  after  giving  careful  attention  to  using  statistically 
sound  parameters. 


Having  validated  the  model,  follow-on  researchers  should  attempt  to 
establish  confidence  intervals  for  the  output  parameters  estimated  by  the 
simulation.  A  basic  limitation  in  the  use  of  simulation  is  the  inability  to  achieve 
exact  answers.  This  is  not  always  a  disadvantage  and  often  provides  satisfactory 
answers  with  reasonable  speed  and  effort.  Often,  however,  it  is  desirable  to 
achieve  a  certain  degree  of  accuracy  in  the  mean  values  of  the  output 
parameters.  Statistically,  the  greater  the  number  of  runs  of  the  model,  the 
higher  the  accuracy  or  degree  of  confidence.  Thus,  it  remains  for  follow-on 
researchers  to  establish  a  desired  degree  of  confidence,  and  then  to  determine 
the  number  of  simulation  runs  needed  to  achieve  that  level  of  confidence. 

Having  a  validated  model  to  work  with  and  an  established  confidence 
interval,  other  investigators  should  conduct  research  to  examine  the  model's 
performance  under  different  environmental  conditions.  A  great  deal  of  emphasis 
by  top  defense  management  personnel  has  been  placed  on  this  country’s  ability 
to  mobilize  its  defense  resources  in  a  national  emergency  or  an  international 
crisis.  Modifying  the  simulation  model  to  replicate  the  jet  engine  repair  cycle  in 
a  wartime  environment  would  provide  beneficial  information. 

The  repair  cycle  and  jet  engine  logistics  support  aboard  aircraft  carriers 
also  represent  unique  logistics  problems  not  found  elsewhere.  The  entire 
logistics  chain  which  feeds  serviceable  engines  to  aircraft  carriers  at  great 
distances  cannot  afford  delays  or  bottlenecks  in  emergency  situations.  Thus,  all 
resources  involved  in  moving  engines  through  this  chain  must  operate  as 
efficiently  and  effectively  as  possible.  A  Q-GERT  network  model  offers  am 
excellent  "first  step"  in  examining  such  a  pipeline. 


Table  II 

Average  Node  Statistics  (in  hours) 


Std.  Deviation 

Average  Std.  Deviation  of  Average 


Minimum 


Maximum 


60.4622 

394.6642 

502.3682 

940.2804 

394.6205 

397.6299 

401.4875 

401.1637 

404.1086 

2277.4214 

2621.1227 

2624.1127 

2621.9671 

2602.6165 

2609.4817 

2644.0943 


0.9344 

121.0296 

139.4191 

137.4196 

120.1126 

120.0594 

119.9208 

119.6260 

119.6627 

144.0010 

158.0313 

157.9992 

159.7578 

161.0411 

159.9619 

166.5269 


0.2955 

38.2729 

44.0882 

43.4559 

37.9829 

37.9661 

37.9223 

37.8290 

37.8407 

45.5371 

49.9739 

49.9637 

50.5199 

50.9257 

50.5844 

52.6604 


58.2142 
187.1995 
308.3892 
730.4155 
186. 1631 
189.4924 
193.4860 
193.9953 
196.9910 
2021.3996 
2408.7907 
2411.9531 
2415.9438 
2378.1947 
2386.1645 
2341.7039 


61.2006 

581.9091 

716.4286 

1149.4733 

579.0867 

582.1599 

586.1801 

587.3556 

590.3745 

2503.5563 

2888.8763 

2891.7288 

2895.6755 

2906.5019 

2914.4771 

2913.2877 


Table  111 


Average  Waiting  Time  (in  hours) 


Std.  Deviation  Max.  Number 
Average  Std.  Deviation  of  Average  in  Q-Node 


0.0980 

0.0269 

0.0085 

278.6157 

118.1905 

37.3751 

0.0596 

0.0290 

0.0092 

0.0000 

0.0000 

0.0130 

0.0115 

0.0036 

0.0000 

0.0000 

0.0000 

1719.5239 

138.6097 

43.8332 

1906.7150 

216.6913 

68.5238 

189.3763 

14.8620 

4.6998 

54.9930 

12.7174 

4.0216 

290.1234 

93.7718 

29.6532 

126.8985 

89.2496 

28.2232 

294.2421 

357.6970 

113.1137 

0.1494 

0.0604 

t  0.0191 

0.0000 

0.0000 

0.0000 

0.0158 

0.0151 

0.0048 

0.0000 

0.0000 

0.0000 

Table  IV 

Average  Number  in  Q-Node 


Std.  Deviation 
Std.  Deviation  of  Average 


Minimum 


Maximum 


0.0042 

0.0012 

0.0004 

0.0020 

0.0062 

12.4644 

5.5960 

1.7696 

2.9908 

21.1748 

0.0023 

0.0011 

0.0004 

0.0014 

0.0052 

0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

0.0005 

0.0004 

0.0001 

0.0000 

0.0011 

0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

58.1768 

6.2765 

1.9848 

50.8551 

72.2064 

16.2272 

2.9021 

0.9177 

11.2782 

19.5791 

3.7825 

0.2335 

0.0738 

3.5404 

4.3078 

0.8022 

0.2146 

0.0678 

0.5661 

1.2307 

0.9543 

0.3248 

0.1027 

0.5460 

1.4859 

0.1219 

0.0950 

0.0300 

0.0146 

0.2994 

0.0654 

0.0672 

0.0212 

0.0000 

0.1470 

0.0028 

0.0011 

0.0003 

0.0014 

0.0048 

0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

0.0003 

0.0003 

0.0001 

0.0000 

0.0006 

0.0000 

0.0000 

0.0000 

0.0000 

0.0000 

Resource 

Number 


Table  V 

Average  Resource  Utilization 


Std.  Std.  Deviation 
Deviation  of  Average 


Max.  # 
Utilized 


1/QEC  Crew 

0.2475 

0.0063 

0.0020 

0.2347 

0.2557 

2/TS  Crew 

0.3958 

0.0042 

0.0013 

0.3903 

0.4046 

3/P-6.8  Crew 

10.0000 

0.0000 

0.0000 

10.0000 

10.0000 

4/P-408  Crew 

2.0000 

0.0000 

0.0000 

2.0000 

2.0000 

5/QEC  W/S 

0.2475 

0.0063 

0.0020 

0.2347 

0.2557 

6/Repair  W/S 

15.9940 

0.0077 

0.0024 

15.9758 

16.0000 

7/Test  Cell 

0.2267 

0.0030 

0.0009 

0.2223 

0.2330 

Resource 

Number 


Table  VI 

Average  Resource  Availability 


Std.  Std.  Deviation 
Deviation  of  Average  Min. 


Max.  if 

Max.  Avai lable 


Appendix  A:  Squadron  Homebasc  Locations  for  the  ]— ~2 
(Source:  9;  28) 


Activity 

Location 

VA  -  34 

NAS  Oceana,  Va. 

VA  -  35 

NAS  Oceana,  Va. 

VA  -  42 

NAS  Oceana,  Va. 

VA  -  45 

NAS  Key  West,  FI. 

VA  -  52 

NAS  Whidbey  Island,  Washington 

VA  -  65 

NAS  Oceana,  Va. 

VA  -  75 

NAS  Oceana,  Va. 

VA  -  85 

NAS  Oceana,  Va. 

VA  -  95 

NAS  Whidbey  Island,  Washington 

VA  -  115 

NAS  Whidbey  Island,  Washington 

VA  -  127 

NAS  Lemoore,  Calif. 

VA  -  128 

NAS  Whidbey  Island,  Washington 

VA  -  145 

NAS  Whidbey  Island,  Washington 

VA  -  165 

NAS  Whidbey  Island,  Washington 

VA  -  176 

NAS  Oceana,  Va. 

VA  -  196 

NAS  Whidbey  Island,  Washington 

VAK  -  208 

NAS  Alameda,  Calif. 

VAK  -  308 

NAS  Alameda,  Calif. 

VAQ  -  33 

NAS  Norfolk,  Va. 

VAQ  -  129 

NAS  Whidbey  Island,  Washington 

VAQ  -  130 

NAS  Whidbey  Island,  Washington 

VAQ  -  131 

NAS  Whidbey  Island,  Washington' 

VAQ  -  132 

NAS  Whidbey  Island,  Washington 

VAQ  -  133 

NAS  Whidbey  Island,  Washington 

VAQ  -  134 

NAS  Whidbey  Island,  Washington 

VAQ  -  135 

NAS  Whidbey  Island,  Washington 

VAQ  -  136 

NAS  Whidbey  Island,  Washington 

VAQ  -  137 

NAS  Whidbey  Island,  Washington 

VAQ  -  138 

NAS  Whidbey  Island,  Washington 

VAQ  -  139 

NAS  Whidbey  Island,  Washington 

VAQ  -  209 

NAS  Norfolk,  Va. 

VAQ  -  309 

NAS  Whidbey  Island,  Washington 

VC  -  1 

NAS  Barber's  Point,  Hi. 

VC  -  5 

NAS  Cubi  Point,  PI. 

VC  -  8 

NAS  Roosevelt  Roads,  PR. 

VC  -  10 

NAS  Guantanamo  Bay,  Cuba 

VC  -  12 

NAS  Oceana,  Va. 

VC  -  13 

NAS  Miramar,  Calif. 

VF  -  43 

NAS  Oceana,  Va. 

VF  -  126 

NAS  Miramar,  Calif. 

65 


VMAQ  -  2 
VMAQ  -  4 
VMAT  -  102 
VMAT  -  202 
VMA  -  121 
VMA  -  211 
VMA  -  214 
VMA  -  223 
VMA  -  224 
VMA  -  242 
VMA  -  311 
VMA  -  331 
VMA  -  332 
VMA  -  533 
VT  -  4 
VT  -  7 
VT  -  21 
VT  -  22 
VT  -  24 
VT  -  25 
VT  -  86 
VX  -  4 
VX  -  5 
H&MS  -  32 
H&MS  -  13 
H&MS  -  10 
H&MS  -  12 
H&MS  -  31 
H&MS  -  24 
H&MS  -  14 
Blue  Angels 
NAS  Patuxent  River 
Naval  Weapons  Center 
NAS  Point  Mugu 
Navy  Fighter  Weapons  School 
Grumman  Aerospace  Corp. 


MCAS  Cherry  Point,  N.C. 

NAS  Whidbey  Island,  Washington 
MCAS  Yuma,  Arizona 
MCAS  Cherry  Point,  N.C. 

MCAS  El  Toro,  Calif. 

MCAS  El  Toro,  Calif. 

MCAS  El  Toro,  Calif. 

MCAS  Cherry  Point,  N.C. 

MCAS  Cherry  Point,  N.C. 

MCAS  El  Toro,  Calif. 

MCAS  El  Toro,  Calif. 

MCAS  Cherry  Point,  N.C. 

MCAS  Cherry  Point,  N.C. 

MCAS  Cherry  Point,  N.C. 

NAS  Pensacola,  FL 
NAS  Meridian,  Miss. 

NAS  Kingsville,  Texas 
NAS  Kingsville,  Texas 
M  \r  /'\ase  ^ield,  ~exas 
Nas  Chase  Field,  Texas 
NAS  Pensacola,  FL 
NAS  Point  Mugu,  Calif. 

NAS  China  Lake,  Calif. 

MCAS  Cherry  Point,  N.C. 

MCAS  El  Toro,  Calif. 

MCAS  Yuma,  Arizona 
Iwakuni,  Japan 
Beaufort,  S.C. 

Kaneohe,  Hi. 

MCAS  Cherry  Point,  N.C. 

NAS  Pensacola,  FI. 

Patuxent  River,  Md. 

China  Lake,  Calif. 

Point  Mugu,  Calif. 

NAS  Miramar,  Calif. 

New  York 


Appendix  B:  J— 52  Repair  Site  Classifications  and  Locations 

(Source:  9;  28) 


Organizational  and 
Third  Degree 
Intermediate 


NAS  Roosevelt  Roads,  PR. 
NAS  Dallas,  Texas 
NAS  Alameda,  Calif. 

NAS  Cecil  Field,  FL 
NAS  Memphis,  Tenn. 

NAS  Willow  Grove,  Pa. 
NAVPRO  Long  Beach,  Ca. 
NAS  Point  Mugu,  Calif. 
NAF  Atsugi,  japan 
U.S.S.  Carl  Vinson 
U.S.S.  Midway 
U.S.S.  Coral  Sea 
U.S.S.  Eisenhower 
U.S.S.  Forrestal 
U.S.S.  Saratoga 
U.S.S.  Ranger 
U.S.S.  Independence 
U.S.S.  Kitty  Hawk 
U.S.S.  Constellation 
U.S.S.  America 
U.S.S.  Kennedy 
U.S.S.  Enterprise 
U.S.S.  Nimitz 


Organizational,  Third, 
and  Second  Degree 
Intermediate 


MCAS  Yuma,  Arizona 
NAS  Guantanamo  Bay 
NAVPRO  Bethpage,  N.Y. 
NWEF  Kirkland  AFB 
NAS  Key  West,  FL 
NAS  South  Weymouth,  N.H. 
H&MS  -  24  Kaneohe,  Hi. 
H&MS  -  31  Beaufort,  S.C. 
H&MS  -  12  Iwakuni,  japan 
H&MS  -  32  Cherry  Pt.  N.C 


Organizational,  Third, 
Second,  and  First 
Degree  Intermediate 


NAS  Chase  Field,  Texas 
NAS  Kingsville,  Texas 
NAS  Meridian,  Miss. 

NAS  Oceana,  Va. 

NAS  Miramar,  Calif. 

NAS  Pensacola,  FI. 

NAS  Cubi  Point,  PI. 

NAS  Whidbey  Island,  Wash. 
NAS  Patuxent  River,  Md. 
H&MS  -  42 
H&MS  -  13 
H&MS  -  14 


Depot,  First,  Second,  and 
Third  Degree  Intermediate 


NARF  Jacksonville,  FI 
NARF  Alameda,  Calif. 


*  J-52-P-8B  only 


Appendix  C:  ^ 


Fiscal  Year 


FY-79 
FY-80 
FY-81 
FY-82 
FY-83  * 


■52  IMA  Engine  Turnaround  Time 
(Source:  11) 


Average  No.  of  Pipeline  Days 


36.0 
63.5 
82.7 
96.1 
>  130.0 


The  figure  shown  for  FY-83  was  provided  as  an  estimate  (21;  38)  since  the 
actual  figure  was  not  available. 


Appendix  F:  Phases  in  the  Life  Cycle  of  the  J— 52  Engine 

(Source:  17) 


From  the  standpoint  of  engine  reliability.  Figure  5  illustrates  the 
theoretical  relationship  between  engine  operating  time  and  failure  rate,  and  is 
often  referred  to  as  the  "bathtub  curve."  Superimposed  on  the  graph  are  the 
three  major  phases  in  the  life  of  the  engine. 


Infant 

mortality 


Failure 

rate 


Wear-out 


Operating  hours 


Figure  5.  Typical  Failure  as  a  function  of 
Time  (17:257-258) 


Initial  estimates  by  the  Naval  Engineering  Support  Office  (NESO)  in 
Jacksonville,  FL,  indicated  that  the  J-52-P-6B  and  the  J— 52  -P-8B  would 
experience  a  failure  rate  corresponding  to  Point  A  at  projected  hours,  tQ. 
However,  revised  estimates  based  on  recent  data  suggest  that  this  failure  rate 
is  occurring  at  time,  t^,  which  is  earlier  than  anticipated  (28).  Point  B  reflects 
an  early  upswing  of  the  curve  and  represents  a  more  accurate  estimate  of  the 
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position  of  these  two  engine  models  in  the  "wearout"  phase  of  the  life  cycle. 
Maintenance  and  management  malpractice  were  suggested  as  two  of  the 


Appendix  G:  Background  for  the  Development  of  a 
Computer  Simulation  Model 


Introduction 


This  section  presents  a  considerable  amount  of  discussion  on  the 
background  of  modeling  and  simulation.  The  intent  is  not  to  begin  a  long  journey 
on  the  road  to  the  creation  of  a  manuscript  on  the  topic,  but  to  highlight  some 
basic  concepts  and  features  of  simulation  modeling.  The  assumption  is  made  that 
not  every  reader  is  completely  familiar  with  the  topic,  and  that  a  brief 
background  will  provide  a  common  referrence  point  for  understanding  the  model 
development  in  Chapter  IV.  Although  several  citations  are  made,  Morris  (27)  and 
Shannon  (35)  are  the  main  sources  of  information  for  the  material  in  this 
section. 

.  Three  objectives  are  met  in  this  appendix.  First,  the  concept  of  modeling 
in  general  is  discussed.  Morris  (27:B707)  and  Shannon  (35:ix)  view  this  as  an  art 
in  which  intuition  on  the  part  of  the  modeler  plays  a  key  role. 

Second,  the  topic  of  simulation  as  one  form  of  modeling  is  discussed.  Some 
of  the  basic  principles  or  "building  blocks"  of  simulation  are  presented,  as  well 
as  some  of  the  underlying  assumptions  and  shortcomings  with  which  managers 
must  contend.  The  emphasis  is  not  merely  on  explaining  what  has  already  been 
established,  but  on  alerting  managers  to  some  hidden  imperfections  in  simulation 
modeling  so  that  they  can  use  it  with  discretion  and  imagination. 


Third,  some  specific  network  simulation  models  are  discussed.  Included  in 
this  section  is  a  discussion  on  the  broader  topic  of  activity  networks  in  general, 
as  well  as  a  specific  family  of  network  simulation  languages,  GERT  (Graphical 


Evaluation  and  Review  Technique).  Q-GERT  (for  Queueing  systems),  one  of 
several  members  of  the  GERT  family,  is  the  simulation  language  chosen  for  this 
project.  A  brief  introduction  to  some  of  the  features  and  limitations  of  Q-GERT 
is  also  provided  in  this  section.  In  Appendix  H,  the  reader  is  introduced  to  some 
of  the  elementary,  intermediate,  and  advanced  concepts  of  Q-GERT  to 
facilitate  a  better  understanding  of  the  model  development  in  Chapter  IV. 


The  Art  of  Modeling 


As  previously  stated,  the  process  of  abstraction  and  translation  of  some 
management  phenomenon  into  a  scientific  model  (the  modeling  process)  is 
probably  best  described  as  an  art  in  the  sense  that  it  remains  largely  intuitive. 
Thus,  any  preconceived  set  of  rules  set  forth  for  construction  of  models  would 
have  limited  usefulness  at  best.  Skill  in  modeling  involves  a  sensitive  and 

selective  perception  of  management  situations  (27).  One's  ability  to  being  some 

» 

sort  of  order  out  of  what  appears  to  be  confusion  determines  to  a  great  extent 
the  degree  to  which  models  give  structure  to  experience.  Morris  (27:B709) 
describes  the  art  of  modeling  in  terms  of  three  hypotheses: 


-  The  process  of  model  development  is  a  process  of  elaboration  or 
enrichment  in  which  simple  models  evolve  into  more  elaborate 
models  which  more  nearly  reflect  the  management  situation  at 
hand. 

-  Analogy  or  association  with  previously  well-developed  models 
plays  an  important  role  in  determining  the  starting  point  for  the 
elaboration  or  enrichment  process. 

-  The  elaboration  or  enrichment  process  involves  looping  or 
alternation  procedures 


Morris  (27:B711-B715)  also  offers  seven  suggestions  for  the  experienced  or 


inexperienced  modeler  to  follow  in  constructing  a  model  of  a  management 
problem: 


1.  Factor  the  system  problem  into  simpler  problems.  The  result  is 
several  problems  whose  solutions  are  sub-optimal  or  approximate 
from  the  total  system  viewpoint. 

2.  Establish  a  clear  statement  of  the  deductive  objectives.  This 
involves  clear  statements  of  tKe  model's  objectives  such  as  the 
prediction  of  the  consequences  due  to  various  policies  or  the 
suggestion  of  an  optimal  policy. 

3.  Seek  analogies.  Attempt  to  relate  the  problem  at  hand  with  some 
previously  well-developed  logical  structure.  This  should  be  done 
early  as  an  analogy  may  suggest  a  certain  approach  to  the 
specific  problem. 

4.  Consider  a  specific  numerical  instance  of  the  problem.  The 
specification  of  a  simple  instance  of  the  proElem  often  helps  the 
modeler  to  identify  necessary  assumptions. 

5.  Establish  some  symbols.  Choose  symbols  which  are  suggestive  of 
their  interpretation  and  give  careful  definition  to  each. 

6.  Write  down  the  obvious.  Identify  simple  laws,  input-output 
relations,  ideas  expressed  by  assumptions,  or  consequences  of 
simple,  trivial  problems. 

7-  Once  a  tractable  model  is  obtained,  enrich  it.  If  it  still  remains 
cumbersome  and  overly  complex,  simplify  it. 


Models  are  developed  to  serve  a  multitude  of  quantitative  and  qualitative 
functions  for  managers.  Beyond  a  rough  description  of  a  model  as  simple  or 
complex,  one  must  also  consider  certain  characteristics: 


-  Relatedness.  How  many  previously  known  results  does  the  model 
bring  to  bear  upon  the  problem? 

-  Transparency.  How  obvious  is  the  interpretation  of  the  model? 

-  Robustness.  How  sensitive  is  the  model  to  changes  in  the 
assumptions  which  characterize  it? 

-  F ertility.  How  rich  is  the  variety  of  deductive  consequences 
which  the  model  produces? 


Logistics  models  have  gradually  evolved  over  time  but  have  been  a  key 
element  in  the  planning  and  support  of  military  operations  since  World  War  1L 
The  number  and  complexity  of  veapon  systems  as  well  as  the  availability  of 
modem  technology  have  grown  over  this  period  of  time.  The  result  has  been  a 
significant  change  in  the  nature  of  warfare  and  the  complexity  of  the 
requirements  imposed  on  management.  Accordingly,  Drezner  and  Hillestad  (12:1) 
state  that  logisticians  will  play  an  increasingly  important  role  and  will  have  to 
rely  more  and  more  on  models  to  deal  with  the  complexities  of  procuring, 
maintaining,  and  transporting  military  material,  facilities,  and  personnel. 
Specific  areas  in  which  support  modeling  has  been  successfully  applied  include: 

-  Resource  forecasting, 

-  Maintenance  management  policy-making  including  determination 
of  inspection  and  replacement  intervals,  as  well  as  workload 
scheduling, 

-  Maintenance  facility  location  and  layout,  and 

-  Determination  of  training  and  manpower  requirements  for  the 
maintenance  of  weapon  systems. 

The  Simulation  Process 

Background.  Simulation  has  its  roots  in  the  management  science  discipline. 
It  is  one  of  the  most  powerful  analysis  tools  available  to  those  responsible  for 
the  design,  operation,  and  management  of  complex  systems.  Shannon  (35:ix) 
comments  that  because  it  is  so  poorly  understood,  it  is  as  much  an  art  as  a 


science  and  that  no  firm  rules  or  fixed  outlines  are  available  to  guide  a  systems 
analyst  in  model  development.  Simulation  can  enlighten  or  mislead  a  manager; 
this  depends  Largely  on  the  extent  to  which  he  is  aware  of  certain  implications 
of  the  model's  assumptions,  strengths  and  weaknesses,  benefits  and  costs. 

Management  today  is  becoming  increasingly  difficult  as  the  man-machine 
systems  in  our  age  of  exploding  technology  become  more  complex.  This 
complexity  is  the  result  of  numerous  interrelations  among  the  various  elements 
of  the  systems.  The  emergence  of  the  Systems  Age  (36:5-35)  gave  birth  to  the 
science  of  systems  analysis  which  requires  that  managers  recognize  the  fact 
that  changing  one  aspect  of  a  system  may  very  well  produce  changes  or  create 
the  need  for  changes  in  other  parts  of  the  system.  The  systems  analysis  concept 
continues  to  evolve  as  managers  and  system  designers  refine  their  understanding 
of  the  ramifications  of  changes  in  a  system. 

Webster's  Collegiate  Dictionary  defines  simulation  as  follows:  "to  feign,  to 
attain  the  essence  of,  without  the  reality."  number  of  authors  have  offered 
their  own  definitions  of  simulation  but  Shannon’s  seems  to  capture  the  basic 
idea  in  a  simple  statement: 

Simulation  is  the  process  of  designing  a  model  of  a  real  system 
and  conducting  experiments  with  this  model  for  the  purpose  of 
either  understanding  the  behavior  of  the  system,  or  evaluating 
various  strategies  (within  the  limits  imposed  by  a  criterion  or 
set  of  criteria)  for  the  operation  of  the  system  (35:2). 

Thus,  a  simulation  model  of  a  real  system  is  a  representation  of  a  group  of 
objects  or  ideas  in  some  form  other  than  the  actual  entity  itself.  The  model 
seeks  to  describe  the  behavior  of  the  system,  construct  theories  or  hypotheses 
that  account  for  this  observed  behavior,  and  make  use  of  these  theories  or 
hypotheses  to  predict  future  behavior  of  the  system  as  changes  are  made  to 


system  inputs  or  design. 


Simulation  as  ve  know  it  today  received  its  original  impetus  from 
aerospace  programs  (35:2).  The  literature  today,  however,  is  replete  with 
countless  books,  technical  articles,  papers,  reports,  and  theses  on  the  subject  of 
simulation,  attesting  to  its  widespread  growth  and  impact  in  a  number  of  fields. 
Simulation  models  serve  a  variety  of  functions  (usually  prediction  and 
comparison)  and  come  in  many  forms  (mathematical  models  are  most  common). 
Network  models  using  languages  such  as  Q-GERT  (Queueing-Graphical 
Evaluation  and  Review  Technique)  are  highly  beneficial  in  complex  systems 
because  they  force  the  system  investigators  to  "think  through"  the  steps  that 
are  necessary  in  the  proper  sequence.  Such  a  task  helps  to  identify  important 
interrelationships,  needed  accomplishments,  timing  of  activities  or  processes, 
availability  of  critical  resources,  and  many  other  important  aspects  which  must 
make  the  system  work. 

Advantages  and  Disadvantages  of  Simulation.  One  of  the  dominant 
questions  that  any  systems  analyst  should  be  concerned  with  from  the  very  start 
of  a  project  is,  "When  is  simulation  appropriate?"  Although  it  is  an  extremely 
valuable  and  useful  approach  to  problem  solving,  it  is  certainly  not  a  panacea 
for  all  of  management's  problems.  Nevertheless,  despite  its  lack  of  mathematical 
sophistication  and  elegance,  it  enjoys  status  as  one  of  the  most  widely  used 
quantitative  techniques  employed  in  management  problem  solving.  Tables  Vll  and 
VIII  illustrate  the  relative  popularity  and  preference  for  simulation  among 
practitioners  and  managers. 

To  address  the  question  of  simulation  appropriateness,  it  is  helpful  first  to 
consider  the  ideal  approach  to  studying  system  behavior.  Obviously,  the  greatest 


Topic 


Value 


Probability  theory  (and  statistical  inference) 

0.182 

Economic  analysis  (cost  effectiveness) 

0.150 

Simulation 

0.143 

Linear  programming 

0.120 

Inventory 

0.097 

Waiting  line  (queueing) 

0.085 

Network  analysis  (sequencing) 

0.072 

Replacement  analysis 

0.042 

Gaming  theory 

0.040 

Dynamic  programming 

:  0.031 

Search  techniques 

0.020 

Non-linear  programming 

0.018 

l.Ooo 

Table  VIU 

Quantitative  Tools  Most  Frequently  Employed  in 


Corporate  Planning  (35:13) 


Topic 

Frequency 

% 

Simulation  studies 

60 

29 

Linear  programming 

43 

21 

Network  analysis 

(including  PERT  &  CPM) 

28 

14 

Inventory  theory 

24 

12 

Non-linear  programming 

16 

8 

Dynamic  programming 

8 

4 

Integer  programming 

7 

3 

Queueing  theory 

7 

3 

Other 

12 

6 
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benefit  would  be  achieved  by  performing  direct  manipulation  of  variables  in  the 
real  life  system  itself  to  eliminate  the  difficulties  in  achieving  a  good  match 
between  the  model  and  actual  conditions.  Barish  (1:454-466),  however,  points 
out  some  obvious  limitations  to  this  approach: 


-  Disruption  of  operations, 

-  Possibility  of  observing  the  "Hawthorne  effect", 

-  Often  more  time  consuming  and  more  costly  than  sampling, 

-  Precludes  exploring  many  alternatives  possible  only  through 
simulation,  and 

-  Difficulty  in  maintaining  stability  in  the  operating  conditions. 


Recognizing  the  infeasibility  of  direct  experimentation,  the  next  step  is  to 
explore  the  limitations  and  potential  usefulness  of  a  simulation  model  of  the 
real  problem.  Shannon  (35:11)  identifies  six  conditions  which  are  favorable  to  its 
use: 


1.  A  complete  mathematical  formulation  of  the  problem  cannot  be 
developed,  or  the  mathematical  procedures  are  so  complex  and 
arduous  that  simulation  provides  a  simpler  method  of  solution. 

2.  Analytical  solutions  exist  but  are  beyond  the  mathematical 
ability  of  available  personnel. 

3.  It  is  desirous  to  observe  a  running  history  of  the  system's 
behavior  rather  than  parameters  at  a  single  point  in  time. 

4.  Simulation  may  be  the  only  possibility  because  of  the  difficulty 
of  observing  phenomena  in  their  actual  environment  -  e.g.,  space 
studies  of  vehicles  in  interplanetary  flight. 

5.  Manipulation  of  time  duration  is  possible  for  processes  with 
extraordinarily  long  or  short  time  frames.  Simulation  affords 
complete  control  over  time,  and  a  phenomenon  may  be  speeded 
up  or  slowed  down  to  enhance  the  investigation  process. 

6.  Simulation  serves  as  a  powerful  educational  and  training  tool. 
The  systems  analyst  can  "play"  with  the  system  and  gain  a 


better  understanding  of  its  workings  as  well  as  a  better  feel  for 
the  specific  problem  being  addressed. 


Similarly,  there  are  times  when  simulation  is  not  the  most  efficient  and 
effective  manner  of  achieving  the  desired  results.  These  disadvantages  include: 

1.  Model  development  is  often  time  consuming,  expensive  and 
dependent  upon  talent  that  may  not  be  readily  available. 

2.  Many  simulation  models  present  a  deceptive  appearance  of 
accurately  reflecting  the  reed  world,  and  this  often  goes 
unnoticed  by  the  systems  analyst. 

3.  Simulation  is  imprecise;  a  sensitivity  analysis  only  partially 
overcomes  this  difficulty. 

4.  The  numerical  results  presented  by  a  simulation  model  are  often 
given  much  more  validity  than  is  justified. 

The  Stages  of  the  Simulation  Process.  To  augment  this  discusssion  on  the 
background  of  simulation  modeling,  the  stages  of  the  simulation  process  are 
presented  (35:21-33).  The  entire  process,  beginning  with  the  identification  of  a 
problem,  is  illustrated  in  the  flowchart  of  Figure  6  and  is  described  below. 

Problem  Identification  and  Formulation.  Shannon  (35:25)  relates  Albert 
Einstein's  comment  that  "the  proper  formulation  of  a  problem  is  even  more 
essential  than  its  solution."  The  initiation  of  a  project  begins  when  someone  in 
the  organization  decides  that  a  problem  exists  and  needs  investigation. 
Unfortunately,  the  communication  of  this  problem  by  management  is  often  vague 
and  reflects  a  lack  of  certainty  about  the  true  nature  of  the  problem.  The 
systems  analyst  must,  therefore,  engage  in  a  preliminary  investigation  and  be 
able  to  articulate  the  problem  (if  it  exists)  in  terms  of  deviations  from  the 
systems  goals  and  objectives. 
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System  Definition.  The  system  boundaries  must  be  determined  in 
addition  to  restrictions  and  measures  of  performance.  This  is  an  important  step 
since  all  systems  themselves  cure  subsystems  of  other  larger  systems. 

Model  Definition  and  Formulation.  The  real  system  under  investigation 
is  reduced  to  a  logical  flowchart  or  a  static  model.  The  desire  is  to  neither 
oversimplify  to  the  point  of  becoming  trivial  (or  worse,  misleading),  nor  to  carry 
it  to  so  much  detail  that  the  model  becomes  clumsy  or  prohibitively  expensive. 
In  this  stage  a  decision  is  made  regarding  the  applicability  of  simulation  to  the 
problem.  Assuming  it  applies,  we  proceed  to  the  next  step. 

Data  Gathering  and  Preparation.  The  data  needed  by  the  systems 
analyst  must  be  identified  and  reduced  to  useable  form.  This  includes  both 
quantitative  and  qualitative  data  pertinent  to  the  problem.  Information  about 
the  inputs  and  outputs  of  the  system,  the  various  components  of  the  system,  and 
the  interdependencies  of  these  components  must  be  specified.  Given  the 
availability  of  this  information,  the  simulation  model  is  then  constructed. 

Model  Translation.  In  this  stage  the  simulation  model  is  described  in  a 
language  acceptable  to  the  computer  to  be  used.  A  number  of  simulation 
languages  are  available  such  as  PERT,  SIMSCRIPT,  SIMULA,  DYNAMO, 
Q-GERT,  and  GPSS,  all  of  which  possess  subtle  differences.  Unfortunately,  the 
choice  of  language  is  often  dictated  by  the  type  of  machine  available  and  the 
language  known  to  the  analyst. 

Validation  of  the  Model.  In  a  broad  sense,  validation  is  the  process  of 
bringing  to  an  acceptable  level  the  user's  confidence  that  any  inference  about 


the  system  derived,  from  the  simulation  is  correct.  Shannon  (35:29)  comments 
that  "there  is  no  such  thing  as  a  test  for  validity"  and  that  "it  is  impossible  to 
prove  that  any  simulator  is  a  correct  or  true  model  of  the  real  system."  Three 
criteria  may  be  used,  however,  to  validate  a  model.  First,  it  must  be  determined 
that  the  model  has  face  validity.  This  can  be  done,  for  example,  by  comparing 
sets  of  simulated  results.  The  second  and  third  test  both  involve  extensive  use 
of  statistical  methods  such  as  a  test  of  means  and  variances,  analysis  of 
variance,  regression,  and  non-parametric  tests. 

Strategic  Planning.  In  this  stage  we  are  concerned  with  designing  an 
experimental  process  that  will  yield  the  desired  information.  The  design 
establishes  an  approach  for  collecting  original  information  that  will  provide 
enough  knowledge  about  the  system  under  study  to  allow  valid  inferences  to  be 
drawn  about  its  behavior.  Two  types  of  objectives  may  emerge  from  the  design: 

(1)  determining  the  combination  of  parameter  values  that  will  optimize  response 
variables,  or  (2)  explaining  the  relationships  between  controllable  factors  and 
response  variables. 

Tactical  Planning.  This  is  concerned  mainly  with  the  question  of 
efficiency  and  deals  with  the  determination  of  how  each  of  the  test  runs  of  the 
model  is  to  be  executed.  Primarily,  two  problem  areas  are  resolved:  (1) 
specification  of  the  starting  conditions  as  they  affect  reaching  equilibrium,  and 

(2)  the  necessity  to  estimate  the  precision  of  the  experimental  results  and  the 
confidence  level  attributable  to  the  conclusions  or  inferences  drawn. 

Experimentation  and  Sensitivity  Analysis.  This  phase  involves  the 
running  of  the  model  and  collection  of  desired  information.  Possessing  many 


characteristics  of  a  troubleshooting  process,  this  stage  often  involves  detecting 
flaws  and  oversights  and  making  adjustments  to  the  design  as  appropriate.  In  the 
sensitivity  analysis,  it  is  determined  how  responsive  the  output  answers  are  to 
the  values  of  parameters  and  controllable  variables.  The  analyst  can 
systematically  vary  parameter  or  input  variable  values  and  observe  the  effects 
upon  the  response  of  the  model.  Simulation  is  ideally  suited  for  a  sensitivity 
analysis  because  of  the  experimenter's  degree  of  control.  Sensitivity  often 
becomes  extremely  important  when  many  of  the  parameters  or  input  variables 
are  based  on  questionable  data. 

Interpretation.  This  phase  involves  drawing  inferences  from  the  data 
generated  by  the  simulation.  The  user  must  be  concerned  not  only  with  the 
obvious  implications  of  the  data,  but  also  with  implications  or  inferences  that 
appear  obvious  but  are  a  part  of  an  interacting  set  of  variables.  In  other  words, 
before  initiating  corrective  action  based  on  an  inference  from  the  data,  aU 
inferences  must  be  considered  in  the  context  of  the  entire  system. 

Implementation.  Shannon  (35:32)  remarks  that  "no  simulation  project 
can  be  considered  successfully  completed  until  it  has  been  accepted,  understood, 
and  used."  Implementation  is  a  key  step  in  achieving  that  success.  Rubenstein 
(33:B508-B518)  found  that  one  of  the  greatest  causes  of  failure  in  operations 
research  and  management  science  projects  was  the  user's  inadequate 
understanding  of  the  results,  and  thus  a  lack  of  implementation.  Supporting  this 
point,  Gershefski  (16)  found  that  the  median  percentage  of  total  model 
development  time  devoted  to  implementation  was  around  10%.  Shannon  (35:33) 
contends  that  this  figure  should  be  around  25%  for  successful  implementation. 


Documentation.  Careful  and  complete  documentation  of  every  aspect 
of  the  development  of  the  model  and  its  operation  will  reap  many  benefits  to 
future  users.  This  facilitates  easier  modification  when  required  and  ensures 
uninterrupted  use  of  the  model  even  when  the  services  of  the  original 
developers  are  no  longer  available.  Careful  documentation  also  helps  the 
modeler  to  learn  from  his  mistakes. 


Justification  for  Choosing  the  Simulation  Approach.  The  choice  of  this 
approach  to  analyzing  the  J— 52  repair  process  was  based  largely  on  its  tendency 
to  be  more  directly  concerned  with  the  wider  organizational  system  issues 
rather  than  a  specific  objective  which  would  be  addressed  by  some  optimization 
model.  The  system  upon  which  the  simulation  model  focusses  in  this  project  is 
the  intermediate  level  repair  cycle  and  not  the  entire  J-52  logistics  support 
effort.  Drawing  on  stored  data  files  and  generating  relevant  output  information, 
simulation  offers  a  powerful  model-based  decision  making  tool  for  engine 
management  personnel.  Keen  and  Morton  offer  a  comment  on  the  value  of 
simulation  which  underlies  the  main  reason  for  its  selection  in  this  project:  "The 
value  of  a  simulation  is  that  it  often  replicates  a  manager’s  environment  in  his 
or  her  own  terms  and  makes  it  possible  to  test  alternatives  (22:46)." 


Network  Simulation  Models 


This  section  focusses  on  the  third  objective  of  this  chapter  -  familiarizing 
the  reader  with  network  models  and  simulation  languages.  It  accomplishes  this 
by  first  discussing  some  of  the  broader  concepts  of  network  simulation  models 
and  eventually  narrows  the  scope  down  to  the  specific  language  of  Q-GER  f  (for 
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Queueing  systems). 

Activity  networks  and  GERTs  (Graphical  Evaluation  and  Review 
Techniques)  are  discussed  before  introducing  Q-GERT  in  order  to  assist  the 
reader  in  visualizing  the  relationship  of  Q-GERT  to  the  overall  scheme  of 
network  simulation  languages.  Figure  7  is  provided  to  help  illustrate  this 
relationship.  Some  of  Q-GERTs  features  and  limitations  are  also  presented  in 
this  section.  Further  details  on  Q-GERT  network  symbology  is  found  in 
Appendix  H. 


Classification  and  Structure  of  Simulation  Models  Simulation  models  are 
classified  in  a  number  of  ways  (35:7-10)  including  the  familiar  static  vs. 
dynamic,  deterministic  vs  stochastic,  discrete  vs.  continuous,  and  iconic  vs. 
analog.  Researchers  will  often  resort  to  combinations  of  these  models  to  more 
accurately  depict  a  complex  system.  Likewise,  many  systems  or  subsystems  may 
be  represented  by  more  than  one  type  of  model  independently. 

The  building  blocks  which  form  the  structure  of  simulation  models  range 
from  simple  to  complex  combinations.  Underlying  the  structure  of  all  models, 
however,  is  the  simple  mathematical  expression. 

E  =  Hx-.y^) 

where 

E  is  a  measure  of  the  system's  performance, 

xVs  are  the  variables  and  parameters  under  our  control, 

y/s  are  the  variables  and  parameters  we  cannot  control,  and 

f  is  an  expression  which  describes  the  relationship  between  x-.y^,  and  E. 
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The  structure  of  almost  every  model  includes  components,  variables, 
parameters,  functional  relationships,  constraints,  and  criterion  functions.  The 
extent  to  which  these  ingredients  are  molded  together  in  detail  will  often 
prescribe  the  similarity  between  a  model  and  the  real  system  it  represents.  An 
identical  correspondence  gives  rise  to  an  isomorphic  model,  while  a  homomorphic 
model  is  similar  in  form  but  different  in  fundamental  structure. 

Model  simplification  is  a  concept  closely  related  to  the  foregoing 
discussion  on  stucture.  It  entails  the  process  of  stripping  away  the  unimportant 
details  or  the  act  of  boldly  stating  certain  assumptions  of  simpler  relationships. 
Simplification  is  an  essential  part  of  developing  a  simulation  model  of  a  complex 
system,  but  must  be  given  careful  attention  to  avoid  losing  certain  capabilities 
of  the  model  (35:17,18). 


Activity  Networks.  The  complex  industrial  and  economic  systems  which 
permeate  our  daily  lives  are  rarely  characterized  by  deterministic  processes. 
Elmaghraby  (13:325)  states,  however,  that  many  of  our  models  are  possessed 
with  the  "curse  of  determinateness."  Most  systems  are  characterized  by  states 
and  transitions  from  one  state  to  another.  These  transitions  often  occur  in  a 
probabilistic  fashion  and  can  be  caused  by  changes  in  time,  cost,  resources, 
location,  and  size.  For  this  reason,  generalized  activity  networks  (GANs)  were 
developed  which  allow  managers  to  study  these  systems  with  probabilistic 
activities.  Although  the  details  of  GAN's  are  not  covered  here,  they  generally 
consist  of  some  basic  "building  blocks"  differing  primarily  in  the  various  node 
and  branch  structures  and  relationships. 


GERT  (Graphical  Evaluation  and  Review  Techique).  GERT  represents  a 


special  case  of  the  GANs  and  is  considerably  easier  to  treat  mathematically. 
The  GERT  network  itself  is  a  signal  flow graph.  These  graphical  representations 
originated  in  the  study  of  electrical  networks  in  the  early  1950's  and  have 
gained  widespread  popularity  in  the  modeling  of  numerous  systems.  GERT 
employs  signal  flowgraph  theory  to  model  systems  which  are  representative  of 
semi-Markov  processes  (those  stochastic  processes  characteristic  of  transitions 
from  one  state  to  another).  Semi-Markov  processes  and  signal  flowgraph  theory 
are  rich  in  mathematical  structure.  Elmaghraby  (13:337-356)  provides  in-depth 
mathematical  coverage  on  the  conversion  of  semi-Markov  processes  to  signal 
flowgraph  symbology,  and  the  topic  is  not  covered  here. 

The  graphical  representation  of  a  GERT  network  usually  accomplishes  two 
objectives:  (1)  assisting  the  manager  in  visualizing  the  total  system,  and  (2) 
assisting  in  understanding  the  interactions  that  take  place  among  the  various 
system  components.  Given  its  name  by  Pritsker  (13:337),  a  GERT  network  is 
really  a  signal  flowgraph*  linking  many  operational  processes  with  stochastic 
features.  It  focusses  on  system  behavior,  given  initial  starting  conditions  (initial 
state).  As  a  modeling  technique,  it  is  applicable  to  problems  in  queueing, 
inventory  control,  reliability,  quality  control,  and  many  other  fields. 

The  discussion  up  to  this  point  has  focussed  on  the  notion  of  GERT  as  a 
signal  flowfraph  representaion  of  a  semi-Markov  process.  These  processes  are 
most  commonly  associated  with  systems  that  possess  no  memory;  that  is,  actions 
or  processes  of  the  future  are  independent  of  the  system's  history.  To  cope  with 
this,  the  analytical  models  of  GERT  gave  way  to  the  devlopment  of  GERTS 
(Graphical  Evaluation  and  Review  Technique  Simulation).  The  same  concepts 
applicable  to  the  GANs  mentioned  earlier  are  applicable  to  GERTS,  but 
expanded  in  more  detail. 

The  main  features  of  GERTS  may  by  summarized  under  two  main  headings: 


(1)  nodes  with  unique  characteristics,  and  (2)  branches  with  unique 
characteristics.  Elmaghraby  (13:360-364)  lists  five  capabilities  offered  by 
GERTS,  but  the  most  significant  of  these  as  it  pertains  to  this  project  is  the 
capability  of  accumulating  statistics  on  the  system  being  modeled.  Time 
measurements  at  various  points  in  the  J— 52  repair  system,  for  example,  are 
determined  by  the  collection  of  time  data  at  certain  nodes.  Using  this  feature,  a 
wealth  of  information  is  achieved  in  the  simulation  including  identification  of 
idle  activities,  the  amount  of  time  incurred  in  various  segments  of  the  pipeline, 
and  the  backlog  status  at  each  point  in  the  system  pipeline. 

GERT  Justification.  The  decision  to  employ  a  GERT  as  the  primary  vehicle 
for  translating  the  real  world  J-52  repair  system  into  computer  language  was 
based  on  its  features  which  make  it  suitable  for  the  type  activities  one 

i 

encounters  throughout  the  repair  process.  To  offer  some  justification  for  the 
choice  of  a  GERT  approach,  a  comparison  with  other  simulation  languages  is 
helpful. 

One  advantage  a  GERT  has  over  a  PERT  (Program  Evaluation  and  Review 
Technique)  is  the  absence  of  certain  restrictions  imposed  on  a  PERT  network 
(13:331).  In  a  PERT  network,  it  is  not  possible  to  repeat  certain  activities  nor 
to  avoid  them,  whereas  a  GERT  may  accomplish  both  of  these  processes.  Since 
the  engine  repair  process  is  characterized  by  individual  repair  requirements  for 
each  engine  (often  requiring  multiple  performance  of  the  same  activity),  a 
GERT  appears  to  conform  neatly  to  the  needs  of  this  project.  Thus,  whereas  a 
PERT  would  be  more  suitable  for  a  steady  state  production  process  where  all 
tranactions  through  the  system  encounter  identical  activities,  a  GERT  possesses 
the  flexibility  to  adapt  to  different  requirements. 


GPSS  (General  Purpose  Simulation  System)  is  another  simulation  language 
which  bears  a  great  deal  of  simularity  to  the  GERT  languages.  Its  ability  to 
handle  queueing  problems  (like  GERTS)  has  made  it  a  popular  choice  of  many 
system  simulators.  GPSS  is  probably  one  of  the  most  widely  used  simulation 
languages  for  job  shop  modeling.  Its  method  of  treating  queue  discipline  is  less 
straight  forward  than  the  treatment  offered  by  a  GERT.  Therefore,  in  the 
interest  of  simplicity,  the  GERT  approach  is  desireable  in  this  project. 

GERT  models  have  been  applied  in  a  number  of  production  settings  where 
waiting  time  represents  a  significant  loss  of  productive  effort.  Other  simulation 
languages  are  available  for  comparison  with  the  GERT  language.  However, 
further  comparison  is  not  carried  out  here.  This  remains  as  a  recommendation 
for  futher  researchers  who  may  desire  to  determine  the  most  appropriate 
simulation  language  for  the  specific  J— 52  repair  system  problem  addressed  in 
this  project. 


Q— GERT  (Queueing— Graphical  Evaluation  and  Review  Technique);  features 
and  limitations.  Controlling  production  time  has  always  been  a  significant  but 
difficult  task  for  managers  concerned  with  production  scheduling  and  proper 
inventory  management.  An  industry  survey  (19)  reported  that  less  than  10%  of 
the  total  production  time  in  an  average  company  is  actual  working  time.  The 
remainder  is  consumed  by  set-up  time,  move  time,  and  wait  time.  The  job 
sequencing  and  priority  dispatching  decisions  made  by  production  managers 
account  for  a  large  part  of  this  non-productive  time.  Day  and  Hottenstein 
(7-11-39)  reviewed  over  160  research  articles  on  the  effects  of  scheduling  and 
sequencing  on  various  measures  of  shop  performance,  giving  extra  attention  to 
both  static  and  dynamic  sequencing. 
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Networks  and  network  analyses  are  playing  an  increasingly  important  role 
in  the  improvement  of  production  systems  and  the  elimination  of  many 
bottlenecks  which  result  in  valuable  lost  time.  This  is  due  largely  to  the  ease 
with  which  systems  can  be  modeled  in  network  form  (32:267).  Q-GERT,  the 
simulation  language  chosen  for  this  project,  offers  just  such  an  approach  for 
analyzing  a  production  system  like  the  J— 52  repair  process.  The  application  of 
this  user-oriented,  simulation  language  offers  invaluable  insights  to  managers  of 
complex  systems  and  creates  a  vehicle  by  which  the  system  weak-points  can  be 
identified.  This  is  precisely  the  rationale  for  developing  a  simulation  model  of 
the  J— 52  repair  process.  Excessive  backlogs  and  idle  activities  cam  be  identified, 
thus  making  it  possible  for  managers  to  reallocate  critical  resources  in  order  to 
increase  the  overall  level  of  effectiveness  and  efficiency  in  all  areas  of  the 
repair  cycle. 

The  most  significant  feature  of  this  entire  simulation  effort  using  Q-GERT 
is  that  it  does  more  than  just  measure  the  system  performance  characteristics; 
it  allows  the  manager  to  "look  ahead"  and  predict  how  these  measures  will  be 
affected  by  implementing  changes  in  the  system  which  are  within  management's 
control  (resource  allocations,  facility  dosings,  procurement  of  additional  parts 
and  equipment,  loss  or  gain  of  manpower,  and  others).  This  is  the  sensitivity 
analysis  phase  and  is  extremely  valuable  to  middle  and  upper  level  engine 
managers. 

A  Q-GERT  network  model  is  characterized  by  many  features  including 
probabalistic  and  deterministic  branching,  network  feedback  loops,  multiple 
probability  distributions  which  describe  the  individual  activity  times,  queue 
nodes  for  systems  where  backlogs  generate  waiting  time,  and  the  option  of 
assigning  attributes  to  specific  transactions  flowing  through  the  system. 

The  basic  provisions  of  Q-GERT  include  some  shop  loading  parameters  such 


as  the  mean  arrival  rate  of  job6,  the  mean  processing  rates  of  the  various  crews 
or  machines  involved,  and  the  number  of  available  machines  or  crews  (7:11-39). 
It  also  includes  the  operational  characteristics  of  the  system  such  as  the 
statistical  distribution  of  the  arrival  rate  of  incoming  jobs,  the  statistical 
distribution  of  the  processing  times,  and  the  procedures  for  routing  jobs  to 
different  activities. 

The  stochastic  nature  of  these  parameters  normally  requires  that  serious 
attention  be  given  to  the  statistical  distributions  of  the  data  in  order  to  reflect 
the  real  system  as  closely  as  possible.  This  phase  of  the  model  development  is 
offered  as  a  challenge  to  follow-on  researchers  dealing  with  J— 52  repair  system 
problems  and  is  not  treated  here.  Instead,  emphasis  is  on  the  development  of  a 
model  which  reflects  the  physical  movement  and  treatment  of  J-52  engines  (and 
resources)  throughout  the  repair  cycle  as  accurately  as  possible. 

Q-GERT,  like  any  other  simulation  language,  has  its  shortcomings  as  well. 
Day  and  Hottenstein  (7:11-39)  list  a  number  of  limiting  assumptions  typically 
made  by  modelers  using  simulations  such  as  Q-GERT.  These  include: 

-  Negligible  transition  times  from  one  activity  to  the  next, 

-  Machines  and  equipment  that  never  break  down, 

-  Levels  of  resources  (people,  tools,  equipment)  that  are  always 
available  to  perform  the  job, 

-  System  performance  parameters  collected  statistically  under 
steady-state  conditions,  and 

-  Poisson  arrival  rates  for  arriving  jobs  and  exponential  service 
times. 

This  list  of  assumptions  could  easily  extend  much  further.  Often  these 
assumptions  can  be  freely  made  without  serious  degradation  of  the  model's 
usefulness.  On  the  other  hand,  incorrect  assumptions  can  also  render  the  results 


of  a  simulation  model  totally  useless.  A  key  point  to  be  made  here  is  that  the 
objective  of  this  thesis  is  to  construct  a  Q-GERT  network  model  which 
replicates  the  physical  operation  of  the  J— 52  repair  system  as  closely  as 
possible.  Emphasis  is  placed  on  model  construction,  not  on  application.  For  this 
reason,  a  number  of  assumptions  are  liberally  applied  to  simplify  the 
construction  of  the  model.  Follow-on  work  in  this  area  cam  concentrate  on 
analyzing  detauled  aspects  of  system  behavior  more  closely,  and  on  converting 
the  assumptions  into  statistically  sound  parameters. 


Appendix  H:  Fundamentals  of  Q— GERT  Networks 

Introduction 

This  section  acquaints  the  reader  with  some  of  the  fundamentals  of  the 
Q-GERT  simulation  language.  In  particular,  some  basic  concepts  of  the  Q-GERT 
network  are  described  in  addition  to  the  symbology  employed  in  a  typical 
network.  The  main  source  for  this  material  is  Pritsker  (31)  who  provides 
excellent  coverage  of  the  material  in  laymen's  terms.  The  material  presented 
here  covers  only  a  brief  introduction  to  the  concepts,  and  the  reader  is 
encouraged  to  consult  Pritsker's  work  for  further  details  on  network  model 
characteristics. 

Q-GERT  involves  the  graphical  modeling  of  systems  in  network  form.  These 
network  models  provide  a  vehicle  through  which  information  about  a  system  can 
be  communicated.  Q-GERT  networks  can  be  automatically  analyzed  to  provide 
statistical  information  to  the  manager  about  the  system  under  study. 

Q-GERT  employs  a  network  philosophy  called  activity-on-branch  in  which  a 
branch  between  two  nodes  represents  an  activity  that  involves  some  amount  of 
processing  time  or  delay.  Flowing  through  the  network  are  items  referred  to  as 
transactions.  These  transactions  are  routed  through  the  network  according  to 
the  branching  characteristics  of  the  nodes.  They  can  represent  physical  objects, 
information,  or  a  combination  of  the  two. 

Different  types  of  nodes  are  included  in  Q-GERT  to  allow  for  the  modeling 
of  complex  queueing  situations.  Activities  can  be  used  to  represent  servers  of 
the  queueing  system.  In  fact,  Q-GERT  networks  can  be  developed  to  model 
sequential  and/or  parallel  server  systems.  Taken  as  a  whole,  the  nodes  and 
branches  of  a  Q-GERT  model  describe  the  structural  aspects  of  the  system. 


Transactions  originate  at  source  nodes  and  travel  along  the  branches  of  the 


network.  Each  branch  has  a  start  node  and  an  end  node  as  shown  below. 


Incoming 

transaction 


Start  node 


End  node 


Branch  representing 
an  activity 


Outgoing 

transaction 


Transactions  moving  across  a  branch  are  delayed  in  reaching  the  end  node 
associated  with  the  branch  by  the  time  required  to  perform  the  activity  that 
the  branch  represents.  When  reaching  the  end  node,  the  disposition  of  the 
transaction  is  determined  by  the  node  type,  the  status  of  the  system,  and  the 
attributes  associated  with  the  transaction.  The  transaction  continues  through 
the  network  until  no  further  routing  can  be  performed.  Typically,  this  occurs  at 
sink  nodes  of  the  network  but  may  occcur  at  other  nodes  to  allow  for  the 
destruction  of  information  flow. 

Transactions  have  attribute  values  that  allow  different  types  of  objects  (or 
the  same  type  of  object  with  different  attribute  values)  to  flow  through  the 
network.  Procedures  are  available  to  assign  and  change  attribute  values  of 
transactions  at  the  various  nodes  of  the  network. 

As  transactions  flow  through  the  network  model,  statistics  are  collected  on 
travel  times,  the  status  of  servers  and  queues,  and  the  times  at  which  nodes  are 
released.  Thus,  a  statistical  data  collection  scheme  is  embedded  directly  in  a 
Q-GERT  network  model.  The  Q-GERT  Analysis  Program  employs  a  simulation 
procedure  to  analyze  the  network.  The  simulation  procedure  involves  the 
generation  of  transactions,  the  processing  of  the  transactions  through  the 


network,  and  the  collection  of  statistics  required  to  prepare  automatically  a 
summary  report  as  dictated  by  the  Q-GERT  network  model. 


From  the  modeler's  viewpoint,  Figure  8  illustrates  the  types  of  problems 
which  must  be  considered  when  developing  a  network  model  of  a  system.  First, 
knowledge  about  the  system  components  must  be  acquired.  Second,  the 
interaction  of  these  components  and  their  general  behavioral  characteristics 
must  be  described  by  some  scenario.  Finally,  the  symbology  is  attached  to  the 
network  to  portray  the  system  behavior  graphically.  Once  the  network  model  is 
constructed  and  converted  to  computer  code,  it  is  submitted  to  a  computer 
facility  which  possesses  a  Q-GERT  Analysis  Program.  This  program  analyzes  the 
network  description  in  accordance  with  the  modeler's  specifications  and 
produces  outputs  that  are  used  in  making  inferences  about  the  system  under 
study. 


Elementary  Q— GERT  Symbology 

This  section  is  concerned  primarily  with  providing  the  reader  a  basic 
understanding  of  the  symbology  and  mechanics  of  a  Q-GERT  network.  The 
discussion  covers  the  simplest  form  of  a  network  and  describes  the  concepts 
involved  in  its  construction  as  well  as  the  meaning  of  the  symbology  attached  to 
it.  The  treatment  of  this  topic  is  light  and  the  reader  is  encouraged  to  iearn 
more  by  consulting  Pritsker's  work  (31),  which  serves  as  the  basis  for  the 
material  presented  in  this  entire  section. 


One  final  note  is  necessary.  Q-GERT  possesses  the  capability  for  in-depth 
construction  of  a  network  through  the  use  of  some  advanced  concepts  called 
FORT  RAM  inserts.  This  topic  is  not  addressed  here  but  the  reader  should  be 
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1.  A  One  Server,  Single  Queue  Network  Model. 


The  discussion  of  the  basic  fundamentals  of  a  Q-GERT  network  begins  with 
the  construction  of  a  simple,  three-node,  three-branch  model  of  a  single  server 
queueing  system.  In  this  system,  a  single  line  of  items  forms  before  the  server. 
They  arrive,  possibly  wait,  are  served,  and  depart  the  system.  This  sequence  of 
events,  activities,  and  decisions  is  referred  to  as  a  process.  The  entities  that 
flow  through  the  process  are  called  transactions.  Thus,  a  Q-GERT  network  is  a 
graphical  representation  of  a  process  and  the  flow  of  transactions  through  the 
process. 

Branches  in  the  network  are  graphical  representations  of  activities 
performed  in  the  process.  Thus,  a  service  operation  is  an  activity  and  is 
modeled  by  a  branch.  The  branch  also  represents  the  passage  of  time  in  a 
Q-GERT  network;  that  is,  the  amount  of  time  to  perform  the  service  operation 
is  denoted  by  the  branch.  The  waiting  line  for  transactions  requiring  the  service 
operation  forms  in  the  queue,  denoted  in  the  network  by  a  Q-node.  This 
arrangement  is  depicted  as  follows: 


Q-Node  Service  activity 


The  many  Q-nodes  and  service  activities  in  a  network  are  all  identified 
numerically  by  their  own  node  numbers  and  activity  numbers.  Service  activities 
are  also  assigned  a  value  which  indicates  the  number  of  parallel,  or  concurrent, 
processings  of  transactions  allowed  by  that  branch.  Q-nodes  are  identified 


visually  by  a  "hash"  mark  in  the  lover  right  hand  comer.  The  placement  of  the 
node  number,  activity  number,  and  number  of  parallel  servers  is  accomplished  on 
the  network  as  follows: 


Q-Node  number  Activity  number 


- > 

Number  of  parallel 
servers 


2.  Modeling  the  Arrival  of  Transactions 

Modeling  the  arrival  of  transactions  to  the  system  is  accomplished  if  we 
know,  or  can  make  assumptions  about,  the  statistical  distribution  of  the  time 
between  arrivals  (interarrival  time).  This  is  accomplished  by  a  node  (other  than 
a  Q-node)  with  two  branches  emanating  from  it.  One  branch  routes  the  arriving 
transactions  on  through  the  system  in  a  normal  fashion,  while  the  other  branch 
returns  a  transaction  to  the  input  side  of  the  node  and  causes  the  next  arriving 
transaction  to  be  generated.  Thus,  each  arrival  begets  the  next  arrival  as  shown 
in  the  illustration  below: 

Branch  to  schedule 
next  arriving  transaction 


Normal  routing 
of  transaction 


It  is  important  to  note  here  that  only  Q -nodes  can  have  servers  immediately 
following  them  (identified  by  the  number  in  the  circle).  Nodes  other  than 
Q -nodes  are  not  allowed  to  have  service  activities  immediately  following  them. 
They  cam,  however,  be  identified  by  an  activity  number  (the  number  in  the 
square).  In  fact,  all  branches  in  the  network  are  allowed  to  have  activity 
numbers  which  just  simply  identifies  that  branch,  but  only  Q -nodes  require  both 
an  activity  number  and  server  number. 

Transactions  arriving  at  a  node  other  tham  a  Q-node  can  be  processed 
immediately  without  any  waiting  by  routing  the  transaction  along  the  branches 
leaving  the  node.  The  semi-circle  which  forms  the  right  side  of  the  node 
indicates  "deterministic"  branching  or  routing.  When  deterministic  branching  is 
encountered,  a  sufficient  quantity  of  transactions  are  generated  internally  so 
that  transactions  depart  on  all  branches  e  mama  ting  from  the  node. 

The  interarrival  process  described  above  usually  indicates  the  start  of  the 
system  and  is  given  a  special  symbol  which  identifies  it  as  a  source  node  as 
shown  below: 


Source  nodes  can  be  viewed  as  an  "internal  generator"  of  transactions 
which  flow  through  the  system.  They  do  not  require  an  incoming  transaction  in 
order  to  be  activated  or  released  the  very  first  time.  (Releasing  a  node  is  a 
term  used  to  specify  that  an  incoming  transaction  can  pass  through  the  node 
and  be  routed  according  to  the  characteristics  of  the  node),  'ieyond  the  first 
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release  of  the  node,  however,  the  model  must  have  specified  the  number  of 
subsequent  arrivals  to  the  node  required  before  it  can  release  another 
transaction.  This,  in  essence,  is  the  interarrival  process,  and  is  accomplished  as 
shown  below. 


Initial  number  of 
transactions  required  to 
release  the  node 


Subsequent  number  of 
transactions  required  to 
release  the  node 


3.  Modeling  Departures  of  Transactions 


If  we  desire  the  transaction  to  depart  the  system  after  being  serviced,  this 


is  accomplished  by  a  single  node  as  follows: 


Sink  node 


The  squiggly  line  is  used  to  indicate  a  sink  node  which  specifies  the 
stopping  procedure  to  be  used  when  analyzing  a  Q-GERT  network.  Other 
methods  of  stopping  the  procedure  are  also  available.  A  transaction  passing 
through  a  sink  node,  from  the  modeler’s  viewpoint,  actually  "disappears"  from 


the  system.  By  telling  the  Q-GERT  Analysis  Program  how  many  "sinks"  are  to 
occur,  the  sink  node  monitors  the  number  of  transactions  passing  through  the 
node  and  terminates  the  run  when  that  number  has  been  realized.  This  is  what 
is  meant  by  specifying  the  stopping  criteria  for  the  simulation. 


4.  Combining  the  Concepts 

The  generation  of  a  transaction,  its  waiting  and  service  operations,  and  its 
departure  from  the  system  can  be  put  together  in  a  simple  network  model 
representing  a  single  queue,  single  server  process.  This  model  is  shown  below. 


In  this  simple  system,  transactions  arriving  for  service  may  find  the  server 
busy.  If  this  is  the  case,  the  transaction  takes  its  place  in  the  queue  with  other 
transactions  awaiting  service.  The  order  of  ranking  in  the  queue  is  specified  by 
the  modeler.  The  FIFO  rule  (First-In-First  Out)  is  a  commonly  used  queue 
ranking  procedure.  Other  ways  of  ranking  transactions  in  the  queue  are 
available.  These  include  ranking  in  accordance  with  some  particular  attribute  of 
the  transaction.  (Attributes  are  covered  later). 
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5.  Collecting  Statistical  Information 


Q-GERT  provides  the  capability  for  imbedding  an  information  system  within 
a  network.  The  amount  of  time,  for  example,  that  a  transaction  spends  in  the 
system  can  be  determined  by  computing  the  difference  between  the 
transaction's  departure  time  and  its  arrival  time.  The  "marking"  of  the  time  at 
which  a  transaction  passes  through  a  node  is  accomplished  by  mark  nodes.  This 
is  achieved  simply  by  placing  a  "M"  in  the  lower  center  portion  of  the  node. 
This  "mark"  is  simply  a  record  of  when  a  transaction  last  passed  through  that 
node.  Source  nodes  automatically  mark  transactions  without  the  modeler 
requesting  it. 

When  we  wish  to  record  the  amount  of  time  spent  by  a  transaction  between 
two  points  in  the  system,  we  request  an  "interval  statistic."  This  is  specified  at 
a  node  by  placing  an  T'  in  the  lower  center  portion  of  the  node.  When  the 
transaction  encounters  an  interval  statistics  node,  Q-GERT  computes  the 
difference  between  the  current  time  and  the  time  the  transaction  was  last 
"marked."  Thus,  the  modeler  can  place  mark  nodes  and  interval  statistics  nodes 
at  many  points  in  the  system  and  determine  how  long  the  transaction  spent  in 
various  segments  of  the  system.  This  method  of  collecting  statistics  in  a 
network  makes  Q-GERT  an  ideal  choice  for  analyzing  the  J— 52  repair  system 
where  we  are  concerned  about  bottlenecks  and  backlogs  in  the  system. 

The  diagram  on  the  following  page  represents  a  simple  system  requesting 
interval  statistics.  The  transaction  receives  a  "mark"  time  as  it  passes  through 
node  5.  It  undergoes  a  process  performed  by  one  server  at  activity  three,  and 
then  passes  on  to  node  15.  At  node  15,  the  time  accumulation  since  node  5  is 
collected  and  retained  by  the  program. 


□ 


jl-M  _  1 5J  HI 

Mark  node 
(at  source) 


Interval  statistics 
node 


6.  Q-Node  Specifications 


The  Q-node  contains  additional  information  not  yet  covered  which  relates 
to  the  transactions  in  the  waiting  line  (queue)  awaiting  service.  The 
arrangement  of  this  information  in  the  Q-node  symbol  is  somewhat  different 
than  the  information  covered  for  other  Q-nodes.  The  diagram  below  describes 
this  information  and  shows  its  placement  within  the  Q-node  symbol. 


Initial  number  of  transactions 
waiting  in  the  queue 


Q-node  number 


Maximum  number  of  transactions 
allowed  in  the  queue 
(capacity) 


v  Procedures  for 
ranking  transactions 
in  the  queue 


For  the  purposes  of  illustration,  the  zero  indicates  that  no  transactions  are 
initially  waiting  in  the  queue,  and  the  infinity  symbol  specifies  an  endless 
waiting  line.  Obviously,  many  systems  will  have  transactions  already  waiting, 
and  space  constraints  normally  will  not  permit  an  infinite  queue  capacity. 
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7.  Activity  Durations 


Each  service  activity  on  the  branches  of  a  Q-GERT  network  requires  a 
certain  amount  of  time  to  perform  its  task.  The  service  time  on  a  particular 
branch,  for  example,  may  be  a  constant  two  minutes  for  each  transaction 
getting  service.  On  the  other  hand,  the  exact  time  to  perform  that  service 
activity  may  not  be  known  but  may  instead  be  characterized  by  some  random 
variable.  This  random  variable  may  come  from  some  statistical  distribution  such 
as  the  exponential,  normal,  lognormal,  or  uniform  distribution. 

To  cope  with  this  in  Q-GERT,  the  service  time  on  each  branch  with  service 
activity  is  specified  by  a  function  type  and  a  parameter  identifier.  The  function 
type  simply  denotes  the  statistical  distribution  from  which  service  times  are 
randomly  picked,  and  the  parameter  identifier  is  usually  a  parameter  set  number 
that  points  to  a  location  in  the  program  where  the  values  of  the  parameters  for 
the  function  are  maintained.  The  function  type  and  parameter  identifier  "are 
prescribed  within  a  set  of  parenthesis  on  the  branch,  separated  by  a  comma.  For 
example,  a  service  time  denoted  by 


( NO,  JO 


indicates  that  the  service  time  is  represented  by  a  random  variable  from  the 
normal  distribution,  and  the  parameter  values  for  this  normal  distribution  are 
kept  in  parameter  set  two.  Parameter  values  can  refer  to  such  statistical 


notions  as  the  mean,  minimum  value,  maximum  value,  or  standard  deviation. 


Pritsker  (41)  provides  a  complete  listing  of  the  various  distributions  available, 
their  Q-GERT  code,  and  the  nature  of  the  parameter  identifier. 


8.  Execution  of  the  Q-GERT  Model 


Once  the  system  under  study  has  been  translated  into  a  Q-GERT  network 
model,  all  that  remains  is  the  transformation  of  the  data  specified  on  the 
network  into  a  set  of  punched  cards  (or  equivalent  input  media).  A  key  element 
in  this  step  is  the  preparation  of  the  general  information  card.  In  addition  to 
routine  information  such  as  the  modeler's  name,  the  project  title  or  number,  and 
the  date,  the  general  card  contains  critical  information  regarding  the  operating 
characteristics  of  the  simulation  process.  This  includes  the  number  of  sink  node 
releases  to  end  one  run  and  the  total  number  of  runs  desired  by  the  modeler. 


Imbelllshments  to  the  Basic  Network 

The  foregoing  discussion  of  elementary  Q-GERT  concepts  provided  the 
"building  blocks"  for  this  section.  What  follows  next  is  a  discussion  of  some  of 
the  imbellishments  to  the  basic  network  structure  just  described  which  give 
modelers  additional  flexibility  in  the  modeling  effort. 


1.  Parallel  Servers 


Changing  a  single  server  system  to  a  multiple  server  system  is  a  simple 
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matter,  especially  if  all  the  servers  are  assumed  to  be  identical.  With  multiple 
identical  servers,  np  choice  decision  is  required;  the  transactions  are  simply 
routed  to  the  first  server  who  becomes  available.  This  change  is  made  by  simply 
changing  the  number  in  the  parallel  server  circle  from  one  to  the  desired 
number  of  parallel  identical  servers.  Thus,  in  the  case  illustrated  below,  four 
parallel  servers  are  available  for  performing  identical  processing  on  the 
transactions  in  activity  three. 


(6X,I) 


In  this  example,  if  the  modeler  had  chosen  to  specify  two  transactions 
initially  waiting  in  Q-node  ten  at  the  beginning  of  the  simulation,  this  would 
have  implied  that  all  four  servers  were  busy  initially. 


2.  Balking  of  Transactions 

The  capacity  of  the  queue  is  not  always  infinite.  In  some  instances,  there  is 
limited  waiting  space  for  transactions  seeking  service.  By  specifying  a  limited 
queue  capacity,  the  modeler  must  decide  the  disposition  of  transactions  arriving 
and  finding  the  queue  full.  One  means  of  handling  this  situation  in  Q-GERT  is 
through  "balking."  Balking  occurs  when  a  transaction  does  not  continue  to  seek 
service  if  the  queue  is  full  (it  goes  elsewhere). 
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Two  possibilities  exist  with  balking:  transactions  can  leave  the  system 
(disappear),  or  they  can  be  routed  to  another  part  of  the  network.  The  omission 
of  a  balking  path  presumes  that  balking  transactions  are  all  lost  to  the  system. 
The  inclusion  of  balking  is  denoted  by  a  dash-dot  line  for  the  balking  path.  This 
path  could  represent  a  situation  where,  for  example,  a  customer  finds  the 
waiting  queue  full  and  decides  to  take  care  of  other  business  while  waiting  for 
an  opening  in  the  queue  in  order  to  rejoin  it.  The  diagram  below  illustrates  two 
cases  of  balking.  Note  that  the  time  delay  is  associated  only  with  the  solid  line. 


example,  where  transactions  display  an  exponential  arrival  pattern  70%  of  the 


time. 

Probabalistic  branching  allows  the  modeler  to  represent  just  such  a 
situation  and  is  represented  in  the  network  by  a  triangular  right  hand  side  of 
the  node.  The  individual  probabilities  of  selecting  each  branch  emanating  from 
the  node  are  assigned  to  the  respective  branches.  The  sum  of  these  probabilities 
must,  of  course,  equal  one.  The  diagram  below  illustrates  this  concept.  Two 
transactions  emanate  from  node  5  simultaneously.  The  transaction  going  to  node 
25  results  in  a  probalistic  branching  situation  to  represent  the  "mixed” 
interarrival  rate. 


4.  Accumulating  Transactions 

Earlier  it  was  mentioned  that  nodes  other  than  Q-nodes  specified  the 
number  of  arriving  transactions  required  to  release  that  node.  In  some  instances, 
it  may  be  necessary  to  accumulate  two  or  more  transactions  before  service  can 
be  provided.  When  the  required  number  of  transactions  has  been  accumulated, 
one  single  transaction  of  a  new  type  is  released  to  the  service  activity. 


Closely  related  to  the  concept  of  balking  Is  another  feature  made  possible 
by  Q-GERT  called  blocking.  Recall  that  in  balking  the  transaction  was  either 
lost  to  the  system  or  routed  along  some  alternate  path  with  a  time  delay  when 
the  queue  was  at  maximum  capacity.  An  alternative  to  this  is  to  "freeze"  the 
activity  upstream  until  an  opening  occurs  in  the  queue  the  transaction  is 
attempting  to  join.  A  special  symbol  is  employed  in  the  network  which  retains 
the  transaction  at  its  current  service  activity  (with  service  temporarily  halted) 
until  space  in  the  subsequent  Q-node  becomes  available.  Then  the  action 
resumes  as  normal.  Blocking  is  illustrated  on  node  11  on  the  following  page. 
Service  activity  three  will  be  blocked  as  required.  Q-GERT  performs  all 
blocking,  unblocking,  and  associated  functions  automatically. 


The  concepts  described  thus  far  can  be  combined  in  a  number  of  sequential 
and  parallel  fashions  to  tailor  the  network  to  the  specific  description  of  the 
system  under  study.  Attempting  to  illustrate  all  the  possible  routing  alternatives 
is  a  formidable  task  and  is  not  undertaken  here. 

Nevertheless,  networks  can  be  constructed  to  represent  situations  where  a 
single  server  can  perform  a  variety  of  different  tasks.  This  situation  is  handled 
easily  with  probabilistic  branching.  Following  the  service  activity,  transactions 
can  also  be  routed  to  different  locations  rather  than  all  to  the  same 
destination.  Such  a  case  allows  the  modeler  to  collect  statistics  on  any  segment 
of  the  network  desired  or  joint  statistical  estimates  of  the  total  time  in  the 
system. 

Q— GERT  Intermediate  Concepts 

To  further  the  background  on  Q-GERT  concepts  and  symbology,  some  of  the 
intermediate  concepts  are  presented  next.  These  intermediate  concepts  relate  to 
associating  certain  attributes  with  transactions,  selecting  among  available 
servers  and/or  queues,  and  matching  transactions  with  common  attributes. 
Assigning  attributes  and  using  Selector  nodes  and  Match  nodes  affords  the 


modeler  tremendous  flexibility  in  being  able  to  replicate  a  real  life  system. 


1.  Assigning  Attributes  to  Transactions 

Attributes  are  values  assigned  to  a  transaction.  These  attribute  values  give 
identity  to  a  transaction  and  are  used  to  distinguish  between  types  of 
transactions  or  to  differentiate  between  transactions  of  the  same  basic  type. 
This  feature  allows  the  network  to  process  transactions  differently  based  on  the 
assigned  attribute  values. 

Attributes  are  used  to  affect  three  fundamental  aspects  of  network  logic: 
the  specification  of  time  required  for  a  service  activity  to  process  a 
transaction,  the  ranking  of  transactions  in  queues,  and  the  routing  of 
transactions  from  a  node.  The  number  of  attributes  associated  with  each 
transaction  is  defined  by  the  modeler  through  input  data.  Any  node  in  the 
network  can  be  used  to  assign  attribute  values.  The  "marie"  time  of  a 
transaction,  automatically  assigned  at  source  nodes,  is  one  attribute  that  all 
transactions  possess. 

When  assigning  attribute  values  to  transactions  at  any  given  node,  two 
pieces  of  information  must  be  prescribed:  the  attribute  number  and  the 
computational  procedure  for  determining  the  actual  value  of  that  attribute. 
The  attribute  number  is  simply  any  integer.  The  computational  procedure,  on  the 
other  hound,  is  similar  to  that  for  the  activity  times.  That  is,  a  distribution 
function  type  and  parameter  identifier  cure  used  to  generate  the  attribute  value. 
This  information  is  placed  in  the  central  portion  of  the  node  just  prior  to  the 
node  number.  The  convention  for  this  notation  is  shown  on  the  following  page. 
Attribute  number  one  for  each  transaction  traversing  node  6  receives  a  value 
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which  is  randomly  generated  from  the  normal  distribution  function  specified  by 
parameter  set  3. 


Attribute  number  Parameter  set  identifier  Node  number  ~ 


Multiple  attribute  assignments  are  easily  accomplished  at  a  single  node.  In 
the  instance  below,  attributes  number  one,  three,  and  five  are  assigned  constant 
values  of  10,  20,  and  30,  respectively,  at  node  7.  Nodes  can  also  change  existing 
attribute  values  in  addition  to  assigning  new  ones. 


Attribute  values  are  used  to  distinguish  between  different  types  of 
transactions  as  well  as  to  differentiate  transactions  of  the  same  basic  type. 
Attribute  number  one,  for  example,  could  identify  vehicle  types  by  assigning  a 
constant  of  1  for  cars  or  a  constant  of  2  for  trucks.  Similarly,  attribute  number 
two  could  distinguish  between  truck  types  by  assigning  a  constant  of  10  for 
10-ton  trucks  or  a  constant  of  20  for  20-ton  trucks.  It  logically  follows  from 
this  that  the  three  models  of  the  J  —52  (P-6,  P-8,  P-408)  could  easily  be 


identified  in  a  network  by  designating  one  of  the  attributes  as  the  engine  model 
identifier.  Then  a  constant  of  6,  8,  or  408  could  be  assigned  to  this  attribute  of 
the  individual  transactions  as  appropriate. 

Attribute  numbers  can  also  be  used  to  identify  the  service  or  activity  time 
required  for  that  transaction.  This  is  accomplished  by  using  the  AT  specification 
for  a  branch  (for  ATtribute).  Thus,  if  the  specification  (AT,1)  is  assigned  to  a 
branch,  then  the  time  for  a  transaction  to  traverse  that  branch  is  whatever 
value  is  currently  held  by  attribute  one  for  that  transaction.  This  is  illustrated 
in  the  diagram  which  follows: 


(VL,\  > 


The  actual  mechanics  of  assigning  attribute  values  to  transactions  are 
accomplished  through  the  use  of  VAS  (Value  Assignment)  input  card.  The  details 
of  this  procedure  are  covered  thoroughly  in  Chapter  5  of  Pritsker  (41:132-188) 
and  are  not  dealt  with  here. 

Another  handy  feature  of  attributes  is  the  ability  to  rank  transactions  in 
the  queue  in  accordance  with  the  value  of  a  specified  attribute.  In  the 
illustration  on  the  following  page,  the  B/2  ranking  specifies  that  the  transaction 
in  the  queue  with  the  biggest  value  of  attribute  two  is  given  priority  for 
processing.  Thus,  it  will  become  the  first  one  to  leave  the  queue  whenever  a 


server  becomes  available. 
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If  the  queue  ranking  rule  is  to  be  determined  by  the  smallest  value  of 
attribute  two,  then  the  notation  S/2  is  specified.  Similarly,  B/M  and  S/M  rank 
transactions  in  the  queue  based  on  the  biggest  value  and  smallest  value  of  mark 
time,  respectively.  The  usefulness  of  this  convention  is  readily  apparent  in 
situations  where  it  is  desired  to  process  transactions  which  have  been  in  the 
system  the  longest. 

The  elementary  aspects  of  deterministic  and  probabilistic  branching  were 
discussed  previously.  With  attributes,  Q-GERT  allows  the  modeler  to  base 
branching  decisions  on  the  current  status  of  the  system  or  on  attribute  values 
assigned  to  transactions.  This  is  known  as  conditional  branching.  Two  types  of 
conditional  branching  occur  when  using  attributes:  conditional  breinching-takc 
first,  and  conditional  bcanchine-take  alL 


In  both  cases,  condition  codes  are  specified  on  the  branches  emanating  from 
the  node.  The  condition  must  be  satisfied  if  the  transaction  is  to  be  routed 
along  that  branch.  These  codes  relate  to  four  system  or  attribute 
characteristics:  time  at  which  routing  is  to  occur,  the  prior  release  of  a  node, 
the  value  of  an  attribute  compared  to  some  criterion  value,  and  the  value  of  an 
attribute  compared  to  the  value  of  another  attribute. 

The  nodes  for  the  two  types  of  branching  are  constructed  differently  to 
allow  easy  recognition  straight  from  the  network.  The  node  for  conditional 
branching-take  first  is  shown  on  the  following  page. 


shown  in  the  following  diagram,  where  every  condition  is  evaluated  and  a 
duplicate  transaction  is  routed  along  each  branch  for  which  the  condition  is 
satisfied. 


The  order  in  which  branches  are  evaluated  is  specified  by  the  modeler  in 
the  input  data.  Also,  there  are  28  possible  condition  codes  that  can  be  specified 
for  a  branch.  These  are  too  numerous  to  cover  here  and  the  reader  is 
encouraged  to  consult  Pritsker's  text. 

Attributes  also  enhance  the  procedures  for  probabilistic  branching  as  well. 
No  major  symbology  change  is  required  and  the  procedure  behaves  in  a  very 
similar  way  as  the  conventional  means  of  probabilistic  branching.  The  main 
extension  feature  is  that  rather  than  having  branches  with  fixed  probabilities, 
attributes  possessing  a  value  for  a  probability  can  be  assigned  to  the  branches. 


In  the  example  below,  transactions  are  routed  to  either  activity  1  or  activity  2 
depending  on  the  probability  values  assigned  to  attributes  1  and  3,  respectively. 


2.  Selector  Nodes  (S-nodes) 

Selector  nodes  are  incorporated  in  a  Q-GE RT  network  to  give  the  modeler 
the  ability  to  invoke  certain  selection  rules  for  governing  the  flow  pattern  of 
transactions.  Two  general  situations  exist  which  make  S-nodes  extremely  useful: 
a  network  of  parallel  queues  before  or  aftlr  a  single  service  activity,  and  a 
single  queue  supplying  transactions  to  a  network  of  parallel,  non-identical 
servers.  The  symbology  for  an  S-node  is  illustrated  below  showing  the  location 
of  the  appropriate  selection  rules. 


Queue  selection 
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Node 
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The  first  case  involves  the  routing  of  transactions  to  parallel  queues. 
Transactions  arrive  along  a  single  branch  and  must  join  one  of  the  parallel 
queues.  A  decision  must  be  made  regarding  which  queue  to  join.  The  S-node 
provides  a  "look  ahead"  capability  by  evaluating  the  queues  linked  to  the  S-node 
and  selecting  one  of  the  queues  according  to  some  selection  rule  specified  by 
the  modeler.  Fourteen  queue  selection  rules  are  available  and  include  such 
codes  as  SNQ  (smallest  number  in  the  queue),  LNQ  (largest  number  in  the 
queue),  and  R  AN  (random  assignment).  This  concept  is  illustrated  below. 


The  second  situation  (shown  below)  is  similar  to  the  first  and  involves 
selection  of  a  transaction  from  parallel  queues  to  feed  into  a  single  service 
activity.  That  is,  transactions  are  waiting  in  each  of  the  parallel  queues  for  the 
single  server  to  become  available.  When  the  server  finally  becomes  available,  a 
choice  is  made  by  the  selector  node  (via  a  queue  selection  rule)  as  to  which 
queue  will  provide  the  next  transaction. 


A  slight  modification  to  this  scheme  results  in  a  very  useful  feature  by 
Q-GERT.  The  transactions  in  the  queues  may  represent  various  subcomponents 
of  a  major  assembly  or  of  a  project  and  the  server  only  processes  "assembled” 
transactions.  Thus,  the  transactions  in  each  of  the  queues  must  be  merged 
together  to  form  an  assembled  unit  before  the  server  can  process  it.  This  case 
arises,  for  example,  when  an  engine  arrives  for  repair  and  must  be  merged  with 
a  repair  crew  and  an  engine  stand  before  the  accomplishment  of  a  service 
activity  (repair  job)  can  take  place.  The  queue  selection  rule  ASM  (Assembly 
Selection  Mode)  accomplishes  this  merger  and  passes  the  completed  unit  on  to 
the  server,  as  shown  below. 


The  third  case  where  selector  nodes  are  helpful  is  when  a  single  queue 
holds  transactions  which  feed  into  two  or  more  parallel,  non-identical  servers. 
The  S-node  invokes  the  prescribed  server  selection  rule  to  make  the  proper 
choice  of  servers.  Eight  selection  rules  are  available  and  it  is  important  to  note 
that  the  server  selection  rule  applies  only  to  a  choice  among  free  servers.  This 
server  selection  case  is  illustrated  on  the  following  page. 
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As  with  the  simple  structures,  balking  and  blocking  are  also  permitted  at 
S-nodes.  In  addition,  many  complex  structures  can  be  put  together  such  as  the 
one  shown  below  where  two  S-nodes  decide  the  routing  of  transactions.  No 
attempt  is  made  here  to  try  to  cover  the  more  elaborate  network  structures. 
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3.  Match  Nodes 


The  last  of  the  intermediate  Q-GERT  concepts  discussed  is  the  match  node. 
Match  nodes  are  nodes  that  match  transactions  residing  in  specified  Q-nodes 
that  have  equal  values  for  a  specified  attribute.  The  match  node  (shown  below) 
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removes  these  transactions  from  the  Q-nodes  and  routes  each  transaction  to  a 
specified  node.  The  difference  between  a  match  node  and  an  S-node  with  the 
ASM  queue  selection  rule  is  that  a  match  node  requires  the  transactions  to  have 
the  same  values  for  a  specified  attribute,  while  the  S-node  does  not. 

Matching  attribute 
number 

Nodes  receiving 
transactions 
with  common 
attribute  values 

Q-nodes  where  Match  node 

match  is  required  number 

When  a  transaction  in  each  of  the  Q-nodes  on  the  left  has  a  common  value 
for  the  matching  attribute  number,  the  match  node  routes  these  transactions 
individually  to  their  respective  receiving  node.  Match  nodes  cure  often  employed 
as  logic  switches  in  a  network.  They  are  also  used  to  model  situations  in  which 
a  transaction  must  wait  for  a  signal  before  proceeding  in  the  network. 

Advanced  Q—GERT  Concepts 

A  number  of  situations  exist  in  production,  finances,  and  several  other 
industries  where  it  is  necessary  to  assign  certain  resources  to  a  transaction  in 
order  to  successfully  process  the  transaction.  Such  is  the  case  in  the  J— 52 
repair  system,  for  example,  where  an  engine  requiring  repair  must  have  an 
available  workstand  and  repair  crew  assigned  to  it  before  repair  can  be 


accomplished.  In  Q-GERT,  it  is  possible  to  halt  the  flow  of  a  transaction  until  a 
specific  resource  type  becomes  available  to  be  allocated  to  the  transaction. 
Allocate  and  Free  nodes  are  the  mechanisms  which  accomplish  this.  Alter  nodes 
also  play  a  role  in  determining  resource  capacity.  Together,  these  three  nodes 
represent  only  a  few  of  Q-GERT's  more  advanced  features,  and  are  discussed 
briefly  in  this  section. 

1.  Allocate  Nodes 

"A  resource  is  defined  as  an  entity  which  is  required  by  a  transaction 
before  the  transaction  can  proceed  through  the  network  (31:355)."  The  different 
types  of  resources  (eg.,  crews,  machines,  space,  stands)  are  defined  by  the 
modeler.  For  each  resource  type,  there  are  three  critical  pieces  of  information 
required  by  the  network:  the  resource  number,  the  number  of  units  of  that 
resource  available,  and  the  total  resource  capacity. 

A  resource  is  allocated  at  various  nodes  in  the  network.  That  is,  it  can 
be  allocated  to  transactions  waiting  in  a  queue  at  one  point,  and  later  allocated 
to  transactions  waiting  in  another  queue.  Once  it  is  allocated  to  a  transaction, 
a  particular  resource  unit  cannot  be  reallocated  until  it  is  no  longer  being  used. 
When  it  finally  becomes  freed,  an  interrogation  procedure  is  employed  by 
Q-GERT  to  determine  the  next  transaction  to  which  the  available  resource 
should  be  allocated. 

As  previously  mentioned,  the  allocate  nodes  assign,  or  allocate,  available 
resources  to  transactions  waiting  in  a  queue.  Thus,  preceding  an  allocate  node 
are  one  or  more  queue  nodes.  When  resource  units  become  available  in  the 
system,  the  allocate  node  selects  from  one  of  the  queues  a  transaction  requiring 


that  type  of  resource.  The  selected  transaction  is  routed  from  its  queue  through 
the  allocate  node  where  it  picks  up  a  resource,  and  the  matched  pair  is  routed 
on  to  a  designated  node.  Resources  allocated  by  an  allocate  node  cure  taken  out 
of  an  available  resource  pool  until  they  become  free  at  some  later  point  in  the 
network. 

The  basic  symbol  for  an  allocate  node  is  shown  below.  In  this  particular 


Queue  Selection 


Node  # 


situation,  transactions  in  queue  node  7  are  assigned  two  units  of  resource 
number  1  by  node  20,  and  the  matched  pair  is  forwarded  on  to  node  8.  The  POR 
queue  selection  rule  (Preferred  Order)  merely  specifies  that  node  7  will  be 
interrogated  first  for  available  transactions  before  node  15.  Many  other  queue 
selection  rules  are  available  including  CYC  (Cyclic  Priority),  RAN  (Random 
Priority),  LNQ  (Largest  Number  of  transactions  in  the  Queue),  and  SNQ  (Smallest 
Number  of  transactions  in  the  Queue). 


2.  Free  Nodes 


Once  a  resource  has  accomplished  its  purpose  with  a  transaction,  the 
desire  is  then  to  free  it  up  so  that  it  becomes  available  for  reallocation  to 
another  transaction.  The  free  node  accomplishes  this  purpose.  A  transaction 
arriving  at  a  free  node  releases  that  node.  This,  in  turn,  causes  a  specified 
number  of  units  of  the  resource  to  be  freed  up  and  placed  back  into  the  pool  of 
available  resources.  Thus,  the  free  node  allows  transactions  to  make  resources 
available.  The  following  diagram  points  out  some  of  the  features  of  the  free 
node  symbol. 
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Note  that  the  list  of  allocate  nodes  in  the  box  at  the  bottom  of  the  free 


node  prescribes  the  order  in  which  allocate  nodes  are  to  be  polled  as  resources 
become  available.  The  objective  achieved  here  is  a  smooth,  orderly  assignment 
of  resources  which  minimizes  their  idle  time. 


3.  Alter  Nodes 


The  last  of  the  advanced  Q-GERT  concepts  to  be  discussed  is  the  alter 
node.  This  useful  feature  allows  the  modeler  to  alter  or  change  the  total 
resource  capacity.  For  example,  it  is  often  desirable  to  model  situations  where 
server  resources  take  lunch  breaks  or  where  machinery  resources  are  inducted 
for  preventive  maintenance.  In  such  cases  the  desire  is  to  decrease  the  total 
number  of  resources  available.  Then  some  time  later,  these  resources  may  be 
brought  back  into  the  picture.  Alter  nodes  accomplish  this  by  making 
adjustments  to  the  total  number  of  resource  units  available  in  the  pool  for 
allocation. 

The  alter  node  is  placed  in  the  network  at  locations  where  it  is  desirable 
for  transactions  to  cause  a  change  (positive  or  negative)  in  the  capacity  of  a 
resource  type.  Alter  nodes  occur  in  a  disjoint  network  (physically  separated 
from  the  main  part  of  the  network)  and  the  capacity  of  the  specified  resource 
number  is  changed  by  some  interger  number  of  units.  The  symbology  which 
follows  illustrates  the  alter  node  concept.  Note  again  the  allocate  nodes  at  the 
bottom  which  are  affected  by  the  change  in  a  resource  capacity. 
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4.  Combining  the  Concepts 


The  diagram  on  the  following  page  illustrates  a  simple  one  server  (one 
resource)  single  queue  model  which  combines  some  of  the  concepts  just 
discussed.  The  server  is  resource  number  one  and  there  are  a  total  of  five 
servers  available  for  assignment.  Transactions  are  generated  at  node  five  and 
they  wait  in  queue  node  ten  until  server  resources  are  allocated  by  allocate 
node  eleven.  Once  the  server  completes  the  job  on  the  transaction,  free  node 
thirteen  frees  up  the  server  for  reallocation  by  node  eleven.  Note  that  the 
disjoint  network  specifies  that  the  total  number  of  units  of  server  resources 
changes  by  minus  three  at  node  twenty-one  and  remains  this  way  for  two  time 
units.  Then  node  twenty-two  increases  them  by  plus  three  to  resume  normal 
capacity  for  five  times  units.  This  could  replicate,  for  example,  a  situation 
where  only  two  repair  crews  are  available  on  weekends  but  five  during  the 
normal  work  week. 

Allocate  Free  Node  Free  Node 
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The  Final  Step 

This  completes  the  discussion  of  Q-GERT  concepts  and  symbology.  Having 
integrated  the  various  symbols  into  a  complete  Q-GERT  network,  the  next  step 
is  translating  the  network  symbology  into  computer  code  acceptable  to  the 
Q-GERT  Analysis  Program.  Chapter  3  of  Prltsker  (31:52-90)  covers  this  phase  in 
detail  and  the  topic  is  not  addressed  here.  This  step,  however,  is  a  crucial  part 
of  the  simulation  effort  and  should  not  be  treated  casually.  The  quality  of  the 
output  information  received  is  determined  largely  by  the  care  with  which 
critical  parameters,  values,  and  several  selection  rules  are  chosen.  Pritsker 
discusses  not  only  the  intricate  detail  of  coding  the  input  data,  but  also  the 
procedures  for  specifying  how  statistical  data  is  to  be  collected.  In  addition,  an 
explanation  of  the  Q-GERT  Analysis  Program  Output  Report  is  also  provided  to 
assist  the  modeler  in  interpreting  the  results. 


Appendix  l:  Input  Code  for  Q-GERT  Analysis  Program 
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QEC  build-up  time 


Depot  repair  time 
Transit  to  user 
Initial  repair  time 

E  S 

Awaiting  transit  to  IMA 
Awaiting  processing  at  IMA 
Awaiting  test  cell  crew 
Awaiting  test  cell 
Awaiting  QEC  crew 
Awaiting  QEC  workstand 
Awaiting  P-6/8  crew 
Awaiting  P-408  crew 
Awaiting  repair  workstand 
Awaiting  P-6/8  crew  re-allocation 
Awaiting  P-408  crew  re-allocation 
Awaiting  P-6/8  crew  re-allocation 
Awaiting  P-408  crew  re-allocation 
Awaiting  test  cell  crew 
Awaiting  test  cell 
Awaiting  QEC  crew 
Awaiting  QEC  workstand 

NODES 

Allocation  of  test  cell  crew 
Allocation  of  test  cell 
Allocation  of  QEC  crew 
Allocation  of  QEC  workstand 
Allocation  of  P-6/8  repair  crew 
Allocation  of  P-408  repair  crew 
Allocation  of  repair  workstand 
Allocation  of  P-6/8  repair  crew 
Allocation  of  P-408  repair  crew 
Allocation  of  P-6/8  repair  crew 
Allocation  of  P-408  repair  crew 
Allocation  of  test  cell  crew 
Allocation  of  test  cell 
Allocation  of  QEC  crew 
Allocation  of  QEC  workstand 

E  S 

Release  test  cell  crew 
Release  test  cell 
Release  QEC  crew 
Release  QEC  workstand 


FRE, 

51,  D, 

3,  1, 

47,  57,  36* 

Release  P-6/8  repair  crew 

FRE, 

52,  D, 

4.  1, 

49.  59,  38* 

Release  P-408  repair  crew 

FRE, 

63,  D, 

3,  1. 

47,  57,  36* 

Release  P-6/8  repair  crew 

FRE, 

64,  D, 

4,  1, 

49,  59,  38* 

Release  P-408  repair  crew 

FRE, 

65,  D, 

6,  1, 

40* 

Release  repair  workstand 

FRE, 

74,  D, 

2,  1, 

68,  16* 

Release  test  cell  crew 

FRE, 

75,  P, 

7,  1, 

71,  19* 

Release  test  cell 

FRE, 

82,  D, 

1.  1, 

77.  27* 

Release  QEC  crew 

FRE, 

* 

83.  D, 

5,  1, 

79,  29* 

Release  QEC  workstand 

* 

if 

RESOURCE 

ASSIGNMENTS 

RES, 

1.  2, 

77,  27* 

QEC  crew 

RES, 

2,  2, 

68,  16* 

Test  cell  crew 

RES, 

3,  10, 

47,  57, 

36* 

P-6/8  repair  crew 

RES, 

4,  2, 

49,  59, 

38* 

P-408  repair  crew 

RES, 

5,  4, 

79,  29* 

QEC  workstand 

RES, 

6,  16, 

40* 

Repair  workstands 

RES, 

* 

7,  2, 

71,  19* 

Test  cells 

* 

it 

V  A 

LUE  ASSIGNMENTS 

VAS, 

1,  2, 

CO.l.O,  ! 

5,  CO.l.O* 

Type  removal/engine  status 

VAS, 

2,  2, 

CO, 2.0,  ! 

5,  CO.l.O* 

Type  removal/engine  status 

VAS, 

5,  1. 

CO, 

6.0* 

Engine  model  designator 

VAS, 

6,  1, 

CO, 

8.0* 

Engine  model  designator 

VAS, 

7,  1. 

CO, 

408.0* 

Engine  model  designator 

VAS, 

12,  4, 

CO, 

2.0* 

Repair  capability 

VAS, 

13.  5, 

CO, 

2.0* 

Engine  status 

VAS, 

14,  4, 

CO, 

1.0* 

Repair  capability 

VAS, 

25,  3, 

CO, 

2.0* 

Extent  of  repair 

VAS, 

26,  3, 

CO, 

1.0* 

Extent  of  repair 

VAS, 

86,  3, 

CO, 

1.0* 

Extent  of  repair 

VAS, 

87,  3, 

CO, 

2.0* 

Extent  of  repair 

VAS, 

81,  5, 

CO, 

2.0* 

Engine  status 

VAS, 

* 

90,  5, 

CO, 

2.0* 

Engine  status 

* 

★ 

A  C 

T  l  V  l  T  l  E  S 

ACT, 

1, 

1,  EX,  1, 

1* 

Interarrival  rate;  unscheduled  removals 

ACT, 

2, 

2,  EX,  2, 

2* 

Interarrival  rate;  scheduled  removals 

ACT, 

1, 

3* 

Connector 

ACT, 

2, 

4* 

Connector 

ACT, 

3, 

5,  ,  ,  , 

,  .2* 

Probability  of  P-6 

ACT, 

3, 

6,  ,  ,  , 

,  .6* 

Probability  of  P-8 

ACT, 

3, 

7,  ,  ,  , 

,  .2* 

Probability  of  P-408 

ACT, 

4, 

5,  ,  ,  , 

,  .2* 

Probability  of  P-6 

ACT, 

4, 

6,  ,  ,  , 

,  .6* 

Probability  of  P-8 

ACT, 

4, 

7,  ,  ,  , 

,  .2* 

Probability  of  P-408 

ACT, 

5, 

8,  LO,  3, 

3* 

P-6  transit  to  SSC 

ACT, 

6, 

8,  LO,  3, 

4* 

P-8  transit  to  SSC 

ACT, 

7, 

8,  LO,  3, 

5* 

P-408  transit  to  SSC 

ACT, 

8, 

9* 

Connector 

ACT, 

9, 

10,  NO,  4, 

6,  1* 

Transit  to  IMA 

ACT, 

10,  11, 

NO,  5, 

7,  2* 

Administrative  processing 

ACT, 

11,  12, 

NO,  6,  8 

',  ..05* 

Transit  to  depot 

ACT, 

12,  13, 

LO,  7,  9* 

Depot  repair 

ACT, 

11,  H, 

,  .  32, 

.  .95* 

To  114  A 

ACT, 

14,  15, 

,  ,  33, 

,  .97* 

To  test  cell 

ACT, 

17,  18, 

LO,  8,  10* 

Prepare  engine  for  test  cell 

ACT, 

20,  21, 

LO,  9,  11* 

Pre-induction  test  cell  run 

ACT, 

21,  22* 

Connector 

ACT, 

22,  23* 

Connector 

ACT, 

23.  24* 

Connector 

ACT, 

14,  24, 

,  ,  34, 

,.03* 

Test  cell  run  not  required 

ACT, 

24,  25, 

,  ,  35, 

,  .95* 

To  major  repair 

ACT, 

30,  31, 

NO,  10, 

12* 

QEC  removal 

ACT, 

31,  32* 

Connector 

ACT, 

32,  33* 

Connector 

ACT, 

33,  34* 

Connector 

ACT, 

24,  26, 

,  ,  36,  , 

.05* 

To  minor  repair 

ACT, 

26,  34* 

Connector 

ACT, 

34,  35, 

,  ,  37, 

,  .Al.EQ.6.0* 

Check  for  P-6 

ACT, 

34,  35, 

.  ,  38, 

,  .Al.EQ.8.0* 

Check  for  P-8 

ACT, 

34,  37, 

,  ,  39. 

,  .Al.EQ.408.0* 

Check  for  P-408 

ACT, 

41,  42, 

LO,  11, 

13,  ,  .A3.EQ.2.0* 

Check  for  major  repair 

ACT, 

41,  42. 

LO,  12, 

14,  ,  .A3.EQ.1.0* 

Check  for  minor  repair 

ACT, 

42,  43, 

,  ,  40, 

.  .90* 

To  AWP 

ACT, 

43,  44* 

Connector 

ACT, 

44.  45, 

LO,  13, 

15,  ,  .A3-EQ.2.0* 

AWP  for  major  repair 

ACT, 

44,  45, 

LO,  14, 

16,  ,  .A3-EQ.1.0* 

AWP  for  minor  repair 

ACT, 

45.  46, 

,  ,  43, 

,  .Al.EQ.6.0* 

Check  for  P-6 

ACT, 

45,  46, 

,  ,  44. 

,  .Al.EQ.8.0* 

Check  for  P-8  * 

ACT, 

45.  48, 

,  .  45, 

,  .Al.EQ.408.0* 

Check  for  P-408 

ACT, 

43.  50* 

Connector 

ACT, 

50,  51, 

,  .  46, 

,  ,A1.EQ.6.0* 

Check  for  P-6 

ACT, 

50,  51, 

,  ,  47, 

,  , Al.EQ.8.0* 

Check  for  P-8 

ACT, 

50,  52. 

,  ,  48, 

,  , Al.EQ.408.0* 

Check  for  P-408 

ACT, 

51,  88* 

Connector 

ACT, 

52,  88* 

Connector 

ACT, 

42,  53, 

,  ,  41, 

,.05* 

To  AWM 

ACT, 

53,  50* 

Connector 

ACT, 

53,  54* 

Connector 

ACT, 

54,  55, 

LO,  15, 

17,  ,  .A3.EQ.2.0* 

AWM  for  major  repair 

ACT, 

54,  55, 

LO,  16, 

18,  ,  .A3.EQ.1.0* 

AWM  for  minor  repair 

ACT, 

55,  56, 

,  ,  49, 

,  , Al.EQ.6.0* 

Check  for  P-6 

ACT, 

55,  56, 

,  ,  50, 

,  , Al.EQ.8.0* 

Check  for  P-8 

ACT, 

55,  58, 

,  ,  51, 

,  , Al.EQ.408.0* 

Check  for  P-408 

ACT, 

42,  60, 

,  .  42, 

,  .05* 

No  delays  in  maintenance 

ACT, 

60,  61, 

LO,  17, 

19,  ,  .A3.EQ.2.0* 

Repair  phase 

ACT, 

61,  62, 

LO,  18 

,  20* 

Build-up  phase 

ACT, 

60,  62, 

LO,  19, 

21,  ,  ,A3.EQ,1.0* 

Completion  of  minor  repair 

ACT, 

62,  63, 

,  ,  52, 

,  , Al.EQ.6.0* 

Check  for  P-6 

ACT, 

62,  63, 

,  ,  53, 

,  , Al.EQ.8.0* 

Check  for  P-8 

ACT, 

62,  64, 

,  .  54, 

,  , Al.EQ.408.0* 

Check  for  P-408 

ACT, 

63,  65* 

Connector 

ACT, 

64,  65* 

Connector 

ACT, 

65,  66* 

Connector 

ACT, 

66,  67,  ,  ,  55,  , 

.95* 

ACT, 

66,  89.  ,  ,  56,  , 

.05* 

ACT, 

69,  70,  LO,  23, 

22* 

ACT, 

72,  73,  LO,  20, 

23* 

ACT, 

73,  74* 

ACT, 

74,  75* 

ACT, 

75,  85,  ,  ,  57,  , 

.05* 

ACT, 

85,  86,  ,  ,  59,  , 

.95* 

ACT, 

85,  87,  ,  ,  60,  , 

.05* 

ACT, 

86,  34* 

ACT, 

87,  34* 

ACT, 

75,  89,  ,  ,  58,  , 

.95* 

ACT, 

80,  81,  NO,  21, 

24* 

ACT, 

81,  82* 

ACT, 

82,  83* 

ACT, 

83,  84,  NO,  22, 

25* 

ACT, 

89,  76,„62,„A3.EQ.2.0* 

ACT, 

89,  90,„6l,„A3.EQ.1.0* 

ACT, 

* 

90,  84,  NO,  22,  63* 

★ 

'it 

PAR 

A  M  E 

PAR, 

1,  36.,  0..120.* 

PAR, 

2,  68.,  0.,  240.* 

PAR, 

3,  60.,  0.,  240., 

20.* 

PAR, 

4,  2.,  1.,  3«,  *5* 

PAR, 

5,  48.,  10.,  72.,  12.* 

f 

PAR, 

6,  120.,  48.,  240., 

24.* 

PAR, 

7,  456.,  288.,  624. 

.,  60.* 

PAR, 

8,  3>,1.»  6.,  1.* 

PAR, 

9,  4.,  2.,  16., 

.5* 

PAR, 

10,  3.,2.,  5.,  .5* 

PAR, 

11,  48.,  36.,  96., 

6.* 

PAR, 

12,  12.,  2.,  36., 

6.* 

PAR, 

13,  360.,  0.,  3168., 

48.* 

PAR, 

14,  24.,  0.,  48., 

6.* 

PAR, 

15,  48.,  0.,  96., 

12.* 

PAR, 

16,  12.,  0.,  36., 

6.* 

PAR, 

17,  168.,  48.,  336., 

48.* 

PAR, 

18,  240.,  144.,  360. 

.,  48.* 

PAR, 

19,  24.,  6.,  48., 

8.* 

PAR, 

20,  4.,  2.,  16., 

.5* 

PAR, 

21,  8.,  4«,  16., 

1.* 

PAR, 

22,  60.,  0.,  240., 

20.* 

PAR, 

23,  3*,  1.,  6., 

1.* 

* 


FIN* 


Requires  post-maintenance  test  cell  run 

Post-maint.  test  ceil  run  not  required 

Prepare  engine  for  test  cell  run 

Post-maintenance  test  ceil  run 

Connector 

Connector 

Engine  not  fixed 

Designate  as  minor  repair 

Designate  as  major  repair 

Connector 

Connector 

Engine  fixed  -  needs  QEC 
QEC  build-up 
Connector 
Connector 

Transit  back  to  user 
Check  for  major  repair 
Check  for  minor  repair 
Transit  back  to  user 

R  S 

Interarrival  rate  -  unscheduled  removals 

Interarrival  rate  -  scheduled  removals 

Transit  to  SSC 

Transit  to  IMA 

Administrative  processing 

Transit  to  depot 

Repair  at  depot 

Prepare  engine  for  test  cell  run 
Test  cell  run 
QEC  removal 

Teardown  for  major  repair 

Initial  stage  of  minor  repair 

AWP  for  major  repair 

AWP  for  minor  repair 

AWM  for  major  repair 

AWM  for  minor  repair 

Repair  phase 

Build-up  phase 

Completion  of  minor  repair 

Post-maintenance  test  cell  run 

QEC  build-up 

Transit  back  to  user 

Prepare  engine  for  test  cell  run 


* 


END  OF  INPUT  CODE 
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Repairs  on  jee  engines  of  Naval  aircraft  are  performed  In 
accordance  with  the  three-tiered  concept  prescribed  by  the  Naval 
Aviation  Maintenance  Program  (NAMP)  -  organisational,  intermediate, 
and  depot  level.  At  the  intermediate  level,  the  entire  repair  cycle 
Is  referred  to  as  the  pipeline*  and  includes  time  expended  In  transit, 
storage,  administrative  processing,  actual  repair,  awaiting  maintenance 
(AWM) ,  awaiting  parts  (AWP),  and  test  csill  verification.  Existing  repair 
system  directives  specify  a  standard  turnaround  time)  (TAT)  for  engines 
in  the  repair  cycle  pipeline Vile  cent  data,  however,  suggests  that  the 
aetual^TAT) f or  the  J-S2  engine  Is  almost  four  ti-as  the  standard 
specified  by  the  directive. 

One  approach  to  investigating  this  excessive  time  In  the  pipeline 
is  to  examine  the  operation  of  the  repair  system,  focussing  attention 
on  the  utilization  of  resources.  The  objective  of  this  project  was, 
therefore,  to  develop  a  computer  simulation  model  which  replicates  the 
J-52  Intermediate  level  repair  cycle,  concentrating  on  repair  crews, 
workstands,  and  test  cells  as  the  major  resources  employed.;  The  Intended 
use  of  the  model  Is  as  a  management  tool  by  which  backlogs  and  delays 
at  various  points  in  the  pipeline  ean  be  identif  ied-^fchereby  allowing 
managers  to  adjust  or  reallocate  resources  as  required  to  achieve  a 
more  efficient  operation  and,  hence,  a  lower  TAT.vA  hypothetical 
scenario  based  on  contrived  parameters  was  developed  In  order  to 
convert  the  model  to  code  and  demonstrate  Its  application  on  the  computer. 
The  results  of  a  sample  simulation  show  that  pxcessive  repair  backlogs 
and  delays  as  well  ss  Inefficient  resource  utilization  can.  In  fact,  * 
be  identified  in  the  output,  thereby  paving  the  way  for  management 
to  experiment  with  different  resource  utilization  schemes  In  order  to 
achieve  a  lower  TAT.  . 
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